From martian at seznam.cz Mon Feb 13 17:05:48 2012 From: martian at seznam.cz (=?ISO-8859-2?Q?Martin_Janovsk=FD?=) Date: Mon, 13 Feb 2012 18:05:48 +0100 Subject: osmocombb and usrp In-Reply-To: References: Message-ID: <4F3942EC.4070709@seznam.cz> Hi Paul, I'm fighting a similar problem while using the current development branch of OsmocomBB. Trying to connect to both OpenBSC and OpenBTS using the test SIM that's available in OsmocomBB. I have a Motorola C123. Is this feature supposed to be fully functional at the moment? Before trying to associate, I switched the mobile to the network-select-mode: manual. The latest behavior is that it's not possible to connect to OpenBSC with the following output from the "mobile" OsmocomBB app: OsmocomBB# show cell 1 ARFCN |MCC |MNC |LAC |cell ID|forb.LA|prio |min-db |max-pwr|rx-lev -------+-------+-------+-------+-------+-------+-------+-------+-------+------- 514DCS|230 |10 |0x04b9 |0x0ba8 |no |normal |-110 | 0 |-51 571DCS|230 |09 |0x2058 |0x69d7 |no |normal |-105 | 5 |-66 648DCS|230 |01 |0x6050 |0x3571 |no |normal |-105 | 0 |-69 777DCS|230 |03 |0x1f5e |0x2aba |no |normal |-105 | 0 |-87 OsmocomBB# network select 1 230 10 Network not in list! To force selecting this network, use 'force' keyword OsmocomBB# network select 1 230 10 force OsmocomBB# show ms MS '1' is up, service is limited IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed manual network selection state : M5 no SIM inserted cell selection state: C0 null radio ressource layer state: idle mobility management layer state: MM idle, PLMN search Thanks, Martin > Hello, > > I have a ursp1 working fine and I want to use my c123 to conenct to it > with osmocombb. > > Now I face some problems. First of all I have no sim, so I do: > sim testcard 1 001 01 > > The usrp runs a testnetwork (001 01) > > I don't know how I can associate with the usrp. I tried: > network search (lot of output and also my testnet) > network show (nothing happens) > network select 1 001 01: Network not in list! > > Any idea what I'm doing wrong? Would be really Cool if i could use > opensource only. > > With best regards, > Paul > > From peter at stuge.se Mon Feb 13 17:22:41 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Feb 2012 18:22:41 +0100 Subject: osmocombb and usrp In-Reply-To: <4F3942EC.4070709@seznam.cz> References: <4F3942EC.4070709@seznam.cz> Message-ID: <20120213172241.8141.qmail@stuge.se> Martin Janovsk? wrote: > OsmocomBB# show ms > MS '1' is up, service is limited > IMEI: 000000000000000 > IMEISV: 0000000000000000 > IMEI generation: fixed > manual network selection state : M5 no SIM inserted This looks bad. Did you enable the sim? //Peter From martian at seznam.cz Tue Feb 14 07:58:08 2012 From: martian at seznam.cz (=?UTF-8?B?TWFydGluIEphbm92c2vDvQ==?=) Date: Tue, 14 Feb 2012 08:58:08 +0100 Subject: osmocombb and usrp In-Reply-To: <20120213172241.8141.qmail@stuge.se> References: <4F3942EC.4070709@seznam.cz> <20120213172241.8141.qmail@stuge.se> Message-ID: <4F3A1410.5010006@seznam.cz> Hi Peter and others, Yes, I had enabled the software sim before trying to associate with the BTS. I also defined my IMSI and rebooted the phone afterwards. Maybe, I'd like the people here to answer these questions for me, if possible: Is the "test sim/soft sim/testcard" feature fully functional in the current release of OsmocomBB? (I want to try couple scenarios with a OpenBSC test setup that another student has been running at our faculty. I'm setting up a OpenBTS/USRP scenario too.) Is the sim reader feature in the "mobile" app currently able to work with HW sim cards? (I want to try running the FOSS firmware as a normal phone for a bit.) If my Motorola C123 is sim-locked to some German service provider, do I have to find ways to unlock it to be able to run a Czech sim card or does the OsmocomBB firmware override the sim lock by default? I think I was unsuccessful last time I tried popping one in and enabling it through "OsmocomBB mobile". I can provide more info after I've re-tried this. I hope my questions stick to the spirit of this list well enough, if not, please let me know. Thanks, Martin Dne 13.2.2012 18:22, Peter Stuge napsal(a): > Martin Janovsk? wrote: >> OsmocomBB# show ms >> MS '1' is up, service is limited >> IMEI: 000000000000000 >> IMEISV: 0000000000000000 >> IMEI generation: fixed >> manual network selection state : M5 no SIM inserted > This looks bad. Did you enable the sim? > > > //Peter > From GNUtoo at no-log.org Thu Feb 2 20:20:00 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Thu, 2 Feb 2012 21:20:00 +0100 Subject: Creating a real usable phone using OsmocomBB In-Reply-To: <4F2878E3.6070605@defora.org> References: <20111211105427.GE10252@prithivi.gnumonks.org> <1327670096061-3693227.post@n3.nabble.com> <4F2878E3.6070605@defora.org> Message-ID: <201202022120.00423.GNUtoo@no-log.org> >On the other hand, I am very interested by supporting the Openmoko >Freerunner, having already written a complete embedded telephony >environment for this platform (with interchangeable telephony backend). >See https://trac.hackable1.org/trac/wiki/DeforaOSSmartphone for more >details. The big problem is getting nuttx-bb to run on it. I've tried hard, but I didn't succeed at printing a thing on the serial console or on sercomm console. The sercomm console means the MODEM<->AP serial, using the sercomm API. The serial console means the IRDA<->audio jack<->computer serial console. with osmocombb things are printed on both consoles... I'll try to give more details when I get back from FOSDEM(I've no serial cable for the IRDA with me). and nuttx.bin is less than 64k: -rwxr-xr-x 1 root root 36.2K Jan 7 22:18 nuttx.bin Denis. From acassis at gmail.com Thu Feb 2 23:06:38 2012 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Thu, 2 Feb 2012 21:06:38 -0200 Subject: Creating a real usable phone using OsmocomBB In-Reply-To: <201202022120.00423.GNUtoo@no-log.org> References: <20111211105427.GE10252@prithivi.gnumonks.org> <1327670096061-3693227.post@n3.nabble.com> <4F2878E3.6070605@defora.org> <201202022120.00423.GNUtoo@no-log.org> Message-ID: Hi Denis, On 2/2/12, Denis 'GNUtoo' Carikli wrote: > The big problem is getting nuttx-bb to run on it. > I've tried hard, but I didn't succeed at printing a thing on the serial > console or on sercomm console. > Did you get help from Stefan (aka l--putt) ? I'll try to run NuttX on Motorola W220, then we can work together on this uart issue. Best Regards, Alan From GNUtoo at no-log.org Fri Feb 3 14:18:03 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Fri, 3 Feb 2012 15:18:03 +0100 Subject: Creating a real usable phone using OsmocomBB In-Reply-To: References: <20111211105427.GE10252@prithivi.gnumonks.org> <201202022120.00423.GNUtoo@no-log.org> Message-ID: <201202031518.03064.GNUtoo@no-log.org> >Did you get help from Stefan (aka l--putt) ? I did not try to get help yet, apart from IRC but that failed. (no one knew how to help me). Denis. From dario.lombardo at libero.it Wed Feb 1 09:00:00 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Wed, 1 Feb 2012 10:00:00 +0100 Subject: RSSI firmware In-Reply-To: <4F27E559.80601@steve-m.de> References: <4F27DCCE.8030504@gmx.de> <4F27E559.80601@steve-m.de> Message-ID: sudo ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin sudo ./osmoload memload 0x820000 ../../target/firmware/board/compal_e88/monitor.highram.bin sudo ./osmoload jump 0x820000 This solution works pretty well! ./osmocon -p /dev/ttyUSB0 -m c123xor -c ../../target/firmware/board/compal_e88/monitor.highram.bin ../../target/firmware/board/compal_e88/chainload.compalram.bin I'm not able to make this one working. The fw is downloaded but not run. monitor.highram.bin has been changed into rssi.highram.bin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.lombardo at libero.it Wed Feb 1 09:58:17 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Wed, 1 Feb 2012 10:58:17 +0100 Subject: RSSI firmware In-Reply-To: References: <4F27DCCE.8030504@gmx.de> <4F27E559.80601@steve-m.de> Message-ID: Due to a minor issue in my cable the second solution didn't work. I can confirm that both solutions work well. On Wed, Feb 1, 2012 at 10:00 AM, Dario Lombardo wrote: > sudo ./osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/compal_e88/loader.compalram.bin > sudo ./osmoload memload 0x820000 > ../../target/firmware/board/compal_e88/monitor.highram.bin > sudo ./osmoload jump 0x820000 > > This solution works pretty well! > > ./osmocon -p /dev/ttyUSB0 -m c123xor > -c ../../target/firmware/board/compal_e88/monitor.highram.bin ../../target/firmware/board/compal_e88/chainload.compalram.bin > > I'm not able to make this one working. The fw is downloaded but not run. > > monitor.highram.bin has been changed into rssi.highram.bin. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vplrt at yahoo.com Fri Feb 3 08:47:21 2012 From: vplrt at yahoo.com (Victor P) Date: Fri, 3 Feb 2012 00:47:21 -0800 (PST) Subject: start phone with RSSI firmware In-Reply-To: References: <4F27DCCE.8030504@gmx.de> <4F27E559.80601@steve-m.de> Message-ID: <1328258841.73543.YahooMailNeo@web45804.mail.sp1.yahoo.com> Hello, list! RSSI firmware is really good.? I wanted to ask is any way to start phone with RSSI firmware without everytime loading this?firmware with osmoload. I mean how to load this firmware in ROM and boot phone with it by holding red button? With best wishes, Victor? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kheimerl at cs.berkeley.edu Wed Feb 1 00:53:48 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Tue, 31 Jan 2012 16:53:48 -0800 Subject: gsm322.c Bug Fix Patch Message-ID: Just a quick bug fix to gsm322.c. Basically, there were two commands in an "else" block without brackets, causing the "end = 1023+299" command to execute regardless of the state of index. -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm322.patch Type: text/x-patch Size: 658 bytes Desc: not available URL: From andreas at eversberg.eu Thu Feb 2 07:34:54 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 02 Feb 2012 08:34:54 +0100 Subject: gsm322.c Bug Fix Patch In-Reply-To: References: Message-ID: <4F2A3C9E.8040601@eversberg.eu> Kurtis Heimerl wrote: > Just a quick bug fix to gsm322.c. Basically, there were two commands > in an "else" block without brackets, causing the > > "end = 1023+299" > > command to execute regardless of the state of index. > hi kurtis, thanx for this fix. applied it. can you tell how you found it? what behavior did you experience? best regards, andreas From kheimerl at cs.berkeley.edu Thu Feb 2 07:47:28 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Wed, 1 Feb 2012 23:47:28 -0800 Subject: gsm322.c Bug Fix Patch In-Reply-To: <4F2A3C9E.8040601@eversberg.eu> References: <4F2A3C9E.8040601@eversberg.eu> Message-ID: I'm currently trying to figure out how to (out of GSM spec) get osmocom to camp to a specific ARFCN. I tried using this function and noticed it wasn't limiting the scan as it was supposed to. On Wed, Feb 1, 2012 at 11:34 PM, Andreas Eversberg wrote: > Kurtis Heimerl wrote: >> Just a quick bug fix to gsm322.c. Basically, there were two commands >> in an "else" block without brackets, causing the >> >> "end = 1023+299" >> >> command to execute regardless of the state of index. >> > hi kurtis, > > thanx for this fix. applied it. > > can you tell how you found it? what behavior did you experience? > > best regards, > > andreas > From andreas at eversberg.eu Thu Feb 2 08:04:21 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 02 Feb 2012 09:04:21 +0100 Subject: gsm322.c Bug Fix Patch In-Reply-To: References: <4F2A3C9E.8040601@eversberg.eu> Message-ID: <4F2A4385.2030103@eversberg.eu> Kurtis Heimerl wrote: > I'm currently trying to figure out how to (out of GSM spec) get > osmocom to camp to a specific ARFCN. I tried using this function and > noticed it wasn't limiting the scan as it was supposed to. > try that at the vty: enable conf t ms 1 stick [pcs] write From kheimerl at cs.berkeley.edu Thu Feb 2 08:08:43 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Thu, 2 Feb 2012 00:08:43 -0800 Subject: gsm322.c Bug Fix Patch In-Reply-To: <4F2A4385.2030103@eversberg.eu> References: <4F2A3C9E.8040601@eversberg.eu> <4F2A4385.2030103@eversberg.eu> Message-ID: I think I looked at that... I'll give you some context. We've modified osmocom to "wakeup" a specific tower at a specific ARFCN. We then want to scan and camp on that arfcn as soon as it wakes up (without scanning the rest of the ARFCNs available). If I remember correctly, stick still scans the whole band... but discards them and only attaches to the "stuck" ARFCN, though I could be mistaken. If it works, it will save us a bunch of time. I'll definitely look at it in more depth tomorrow. Thanks for the direction! On Thu, Feb 2, 2012 at 12:04 AM, jolly wrote: > Kurtis Heimerl wrote: >> I'm currently trying to figure out how to (out of GSM spec) get >> osmocom to camp to a specific ARFCN. I tried using this function and >> noticed it wasn't limiting the scan as it was supposed to. >> > try that at the vty: > > enable > conf t > ms 1 > stick [pcs] > write > From alexander.chemeris at gmail.com Thu Feb 2 08:56:14 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 2 Feb 2012 11:56:14 +0300 Subject: gsm322.c Bug Fix Patch In-Reply-To: References: <4F2A3C9E.8040601@eversberg.eu> <4F2A4385.2030103@eversberg.eu> Message-ID: On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl wrote: > I think I looked at that... I'll give you some context. > > We've modified osmocom to "wakeup" a specific tower at a specific > ARFCN. Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? -- Regards, Alexander Chemeris. From kheimerl at cs.berkeley.edu Thu Feb 2 18:03:50 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Thu, 2 Feb 2012 10:03:50 -0800 Subject: gsm322.c Bug Fix Patch In-Reply-To: References: <4F2A3C9E.8040601@eversberg.eu> <4F2A4385.2030103@eversberg.eu> Message-ID: Yeah, and we have that working. On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris wrote: > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl wrote: >> I think I looked at that... I'll give you some context. >> >> We've modified osmocom to "wakeup" a specific tower at a specific >> ARFCN. > > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? > > -- > Regards, > Alexander Chemeris. From alexander.chemeris at gmail.com Thu Feb 2 18:37:25 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 2 Feb 2012 21:37:25 +0300 Subject: gsm322.c Bug Fix Patch In-Reply-To: References: <4F2A3C9E.8040601@eversberg.eu> <4F2A4385.2030103@eversberg.eu> Message-ID: Is it a part of your TIER university work? I wonder about use cases for this. One use case I see is when you have a BTS which is rarely used, like in a desert and you don't want it to work all the time. What use cases do you plan to use it for? On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl wrote: > > Yeah, and we have that working. > > On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris > wrote: > > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl wrote: > >> I think I looked at that... I'll give you some context. > >> > >> We've modified osmocom to "wakeup" a specific tower at a specific > >> ARFCN. > > > > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? > > > > -- > > Regards, > > Alexander Chemeris. -- Regards, Alexander Chemeris. From kheimerl at cs.berkeley.edu Thu Feb 2 18:43:42 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Thu, 2 Feb 2012 10:43:42 -0800 Subject: gsm322.c Bug Fix Patch In-Reply-To: References: <4F2A3C9E.8040601@eversberg.eu> <4F2A4385.2030103@eversberg.eu> Message-ID: This is part of my thesis work at Cal, yes. Range is not in any way involved. That's roughly the use case, areas where there are too few users to keep a BTS in constant use. Our designs allow the power usage to scale with the number of users, rather than sit at a fixed output, as they do now. The BTS side is simple; the osmocom side is complicated. We have a handset that can wakeup a sleeping tower, or a "wakeup button" device which only transmits when a button is pressed. That thing is ~5 bucks and can probably be attached to the back of a legacy phone in case we can't convince a large manufacturer to incorporate our changes into the baseband. Anyhow, the code is online if you're interested in looking at our progress (https://github.com/kheimerl). It's nowhere near ready, but you're a very knowledgeable guy, and I'd be happy to hear your opinions on any of our designs. On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris wrote: > Is it a part of your TIER university work? > I wonder about use cases for this. > > One use case I see is when you have a BTS which is rarely used, like > in a desert and you don't want it to work all the time. What use cases > do you plan to use it for? > > On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl wrote: >> >> Yeah, and we have that working. >> >> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris >> wrote: >> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl wrote: >> >> I think I looked at that... I'll give you some context. >> >> >> >> We've modified osmocom to "wakeup" a specific tower at a specific >> >> ARFCN. >> > >> > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? >> > >> > -- >> > Regards, >> > Alexander Chemeris. > > > > > -- > Regards, > Alexander Chemeris. From alexander.chemeris at gmail.com Fri Feb 3 05:17:09 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 3 Feb 2012 08:17:09 +0300 Subject: Power-savvy GSM network (was: gsm322.c Bug Fix Patch) Message-ID: Hi Kurtis, (I'm changing subject to the actual topic of this discussion) Yes, I quickly looked through your code. Looks like a big hack right now, but I guess it's meant to be a hack at this point :) So, your idea is to manipulate Tx power of a BTS to cover only actually working handsets, if I understand correctly. It's not possible to do with a normal GSM phone, because phone does not transmit until it sees a beacon. So you want to create a "wake up BTS" channel to get around. Am I following your logic correctly? It does look like an interesting idea if could be done dirt-cheap. But how do you plan to do paging in this system? I see the only way - to use the same "wake up channel", but in other direction. So basically you have a network-specific "default" ARFCN which is used when no active BTS is in range. All communications are first tried on this ARFCN and only then on other ones. Right? On Thu, Feb 2, 2012 at 22:43, Kurtis Heimerl wrote: > This is part of my thesis work at Cal, yes. Range is not in any way involved. > > That's roughly the use case, areas where there are too few users to > keep a BTS in constant use. Our designs allow the power usage to scale > with the number of users, rather than sit at a fixed output, as they > do now. The BTS side is simple; the osmocom side is complicated. We > have a handset that can wakeup a sleeping tower, or a "wakeup button" > device which only transmits when a button is pressed. That thing is ~5 > bucks and can probably be attached to the back of a legacy phone in > case we can't convince a large manufacturer to incorporate our changes > into the baseband. > > Anyhow, the code is online if you're interested in looking at our > progress (https://github.com/kheimerl). It's nowhere near ready, but > you're a very knowledgeable guy, and I'd be happy to hear your > opinions on any of our designs. > > On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris > wrote: >> Is it a part of your TIER university work? >> I wonder about use cases for this. >> >> One use case I see is when you have a BTS which is rarely used, like >> in a desert and you don't want it to work all the time. What use cases >> do you plan to use it for? >> >> On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl wrote: >>> >>> Yeah, and we have that working. >>> >>> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris >>> wrote: >>> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl wrote: >>> >> I think I looked at that... I'll give you some context. >>> >> >>> >> We've modified osmocom to "wakeup" a specific tower at a specific >>> >> ARFCN. >>> > >>> > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? >>> > >>> > -- >>> > Regards, >>> > Alexander Chemeris. >> >> >> >> >> -- >> Regards, >> Alexander Chemeris. -- Regards, Alexander Chemeris. From kheimerl at cs.berkeley.edu Fri Feb 3 08:32:12 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Fri, 3 Feb 2012 00:32:12 -0800 Subject: Power-savvy GSM network (was: gsm322.c Bug Fix Patch) In-Reply-To: References: Message-ID: Comments in line! On Thu, Feb 2, 2012 at 9:17 PM, Alexander Chemeris wrote: > Hi Kurtis, > > (I'm changing subject to the actual topic of this discussion) Good idea. > > Yes, I quickly looked through your code. Looks like a big hack right > now, but I guess it's meant to be a hack at this point :) And it will remain a big hack into the near future! > > So, your idea is to manipulate Tx power of a BTS to cover only > actually working handsets, if I understand correctly. It's not > possible to do with a normal GSM phone, because phone does not > transmit until it sees a beacon. So you want to create a "wake up BTS" > channel to get around. Am I following your logic correctly? Ah... sorta not really, unless we're using different terminology. We use the existing channel (that the BTS is listening on) and send a RACH over that channel to the BTS. Though the handset can't hear the beacon, the radio is capable of transmitting at that ARFCN without a beacon (thanks Sylvain!) if we tell it to do so. We do so ("wakeup"), causing the handset to RACH at a specific ARFCN and the BTS to hear some discernible noise (however not a RACH as the clocks are not synced) and turn the PA on. Following this, the handset camps normally and makes a call. In writing that, it is awfully hard to describe. I hope that made some sense. I can tell you that it's working in our lab, and it's pretty cool. > > It does look like an interesting idea if could be done dirt-cheap. But > how do you plan to do paging in this system? I see the only way - to > use the same "wake up channel", but in other direction. So basically > you have a network-specific "default" ARFCN which is used when no > active BTS is in range. All communications are first tried on this > ARFCN and only then on other ones. Right? Paging is actually quite simple, as we own the BTS. When we receive a call, we hold it ("please wait for connection") and turn the PA on. We then wait for the HS to camp, and if they do, page them once available. A little delay (much better with SMS), but I think most users would be fine with it. We haven't written this yet. > > On Thu, Feb 2, 2012 at 22:43, Kurtis Heimerl wrote: >> This is part of my thesis work at Cal, yes. Range is not in any way involved. >> >> That's roughly the use case, areas where there are too few users to >> keep a BTS in constant use. Our designs allow the power usage to scale >> with the number of users, rather than sit at a fixed output, as they >> do now. The BTS side is simple; the osmocom side is complicated. We >> have a handset that can wakeup a sleeping tower, or a "wakeup button" >> device which only transmits when a button is pressed. That thing is ~5 >> bucks and can probably be attached to the back of a legacy phone in >> case we can't convince a large manufacturer to incorporate our changes >> into the baseband. >> >> Anyhow, the code is online if you're interested in looking at our >> progress (https://github.com/kheimerl). It's nowhere near ready, but >> you're a very knowledgeable guy, and I'd be happy to hear your >> opinions on any of our designs. >> >> On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris >> wrote: >>> Is it a part of your TIER university work? >>> I wonder about use cases for this. >>> >>> One use case I see is when you have a BTS which is rarely used, like >>> in a desert and you don't want it to work all the time. What use cases >>> do you plan to use it for? >>> >>> On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl wrote: >>>> >>>> Yeah, and we have that working. >>>> >>>> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris >>>> wrote: >>>> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl wrote: >>>> >> I think I looked at that... I'll give you some context. >>>> >> >>>> >> We've modified osmocom to "wakeup" a specific tower at a specific >>>> >> ARFCN. >>>> > >>>> > Interesting. Do you mean you send some packet to a "sleeping" BTS to wake it up? >>>> > >>>> > -- >>>> > Regards, >>>> > Alexander Chemeris. >>> >>> >>> >>> >>> -- >>> Regards, >>> Alexander Chemeris. > > > > -- > Regards, > Alexander Chemeris. From laforge at gnumonks.org Fri Feb 3 14:08:00 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 3 Feb 2012 15:08:00 +0100 Subject: Power-savvy GSM network (was: gsm322.c Bug Fix Patch) In-Reply-To: References: Message-ID: <20120203140800.GZ9030@prithivi.gnumonks.org> Hi Kurtis, On Fri, Feb 03, 2012 at 12:32:12AM -0800, Kurtis Heimerl wrote: > Paging is actually quite simple, as we own the BTS. When we receive a > call, we hold it ("please wait for connection") and turn the PA on. We > then wait for the HS to camp, and if they do, page them once > available. A little delay (much better with SMS), but I think most > users would be fine with it. We haven't written this yet. I think the delay will be quite significant, depending on where and how the MS is currently scanning and/or trying to register to other networks, I would guess it could easily be 20 to 30 seconds. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kheimerl at cs.berkeley.edu Fri Feb 3 18:35:12 2012 From: kheimerl at cs.berkeley.edu (Kurtis Heimerl) Date: Fri, 3 Feb 2012 10:35:12 -0800 Subject: Power-savvy GSM network (was: gsm322.c Bug Fix Patch) In-Reply-To: <20120203140800.GZ9030@prithivi.gnumonks.org> References: <20120203140800.GZ9030@prithivi.gnumonks.org> Message-ID: I think that's acceptable. I expected a lot longer, to be honest. As an alternative, I could instead just call both parties back once the phone has camped. There's a number of ways to communicate the wait, and I don't think users in rural areas would be particular bothered by the execution. In my own experience in rural Uganda, they went through a lot more hoops (e.g., climbing trees) for coverage. On Fri, Feb 3, 2012 at 6:08 AM, Harald Welte wrote: > Hi Kurtis, > > On Fri, Feb 03, 2012 at 12:32:12AM -0800, Kurtis Heimerl wrote: >> Paging is actually quite simple, as we own the BTS. When we receive a >> call, we hold it ("please wait for connection") and turn the PA on. We >> then wait for the HS to camp, and if they do, page them once >> available. A little delay (much better with SMS), but I think most >> users would be fine with it. We haven't written this yet. > > I think the delay will be quite significant, depending on where and how > the MS is currently scanning and/or trying to register to other > networks, I would guess it could easily be 20 to 30 seconds. > > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) From dani.martinezroca at gmail.com Fri Feb 3 08:17:43 2012 From: dani.martinezroca at gmail.com (canarion) Date: Fri, 3 Feb 2012 00:17:43 -0800 (PST) Subject: Sniffing GPRS Message-ID: <1328257063144-3712433.post@n3.nabble.com> Hi, After compiling osmocom-bb and apply sylvain/burst_ind branch and gprs_multi.patch, I execute it and try to sniff gprs traffic. I loaded the layer1 into my C139 and I obtained an ARFCN code (883). When I run ccch_scan -a 883 I get the next result: opyright (C) 2010 Harald Welte Contributions by Holger Hans Peter Freyther License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1476410343) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1207963561) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x1ad1cda) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x41ae98f9) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214031385056117) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3306441249) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214031482053520) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214036185306441) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4207880193) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135931713) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4214223105) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3388536385) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134915836) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3961436929) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4229756769) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(531909) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214034185316455) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3829437761) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214033485554660) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3639403521) <0001> app_ccch_scan.c:105 SI1 received. <0001> app_ccch_scan.c:464 unknown PCH/AGCH type 0x00 <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3827744513) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(335734299) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3561969409) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4294310401) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3698994241) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3682615617) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(67866789) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4003487553) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3770351169) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x41ae98f9) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1ad1cda) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214031385056117) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3306441249) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214031482053520) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214036185306441) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4102036289) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135931713) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214032485273805) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3798414145) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134915836) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3988859137) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3735175681) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(531909) <0001> app_ccch_scan.c:248 GSM48 IMM ASS (ra=0x78, chan_nr=0x0f, HSN=24, MAIO=1, TS=7, SS=0, TSC=1) Dropping frame with 55 bit errors <000c> l1ctl.c:238 Dropping frame with 55 bit errors <000c> l1ctl.c:290 BURST IND: @(830928 = 0626/20/36) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830928 = 0626/20/36) (-110 dBm, SNR 8) <000c> l1ctl.c:290 BURST IND: @(830929 = 0626/21/37) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830929 = 0626/21/37) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830930 = 0626/22/38) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830930 = 0626/22/38) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830931 = 0626/23/39) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830931 = 0626/23/39) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830932 = 0626/24/40) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830932 = 0626/24/40) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830933 = 0626/25/41) (-105 dBm, SNR 8, UL, SACCH) <000c> l1ctl.c:290 BURST IND: @(830933 = 0626/25/41) (-107 dBm, SNR 5, SACCH) <000c> l1ctl.c:290 BURST IND: @(830934 = 0626/00/42) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830934 = 0626/00/42) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830935 = 0626/01/43) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830935 = 0626/01/43) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830936 = 0626/02/44) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830936 = 0626/02/44) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830937 = 0626/03/45) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830937 = 0626/03/45) ( -89 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830938 = 0626/04/46) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830938 = 0626/04/46) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830939 = 0626/05/47) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830939 = 0626/05/47) ( -82 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830940 = 0626/06/48) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830940 = 0626/06/48) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830941 = 0626/07/49) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830941 = 0626/07/49) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830942 = 0626/08/50) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830942 = 0626/08/50) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830943 = 0626/09/00) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830943 = 0626/09/00) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830944 = 0626/10/01) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830944 = 0626/10/01) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830945 = 0626/11/02) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830945 = 0626/11/02) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830947 = 0626/13/04) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830947 = 0626/13/04) ( -84 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830948 = 0626/14/05) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830948 = 0626/14/05) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830949 = 0626/15/06) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830949 = 0626/15/06) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830950 = 0626/16/07) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830950 = 0626/16/07) ( -89 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830951 = 0626/17/08) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830951 = 0626/17/08) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830952 = 0626/18/09) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830952 = 0626/18/09) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830953 = 0626/19/10) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830953 = 0626/19/10) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830954 = 0626/20/11) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830954 = 0626/20/11) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830955 = 0626/21/12) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830955 = 0626/21/12) (-106 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830956 = 0626/22/13) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830956 = 0626/22/13) (-107 dBm, SNR 5) <000c> l1ctl.c:290 BURST IND: @(830957 = 0626/23/14) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830957 = 0626/23/14) (-106 dBm, SNR 2) <000c> l1ctl.c:290 BURST IND: @(830958 = 0626/24/15) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830958 = 0626/24/15) (-108 dBm, SNR 1) <000c> l1ctl.c:290 BURST IND: @(830959 = 0626/25/16) (-106 dBm, SNR 2, UL, SACCH) <000c> l1ctl.c:290 BURST IND: @(830959 = 0626/25/16) (-109 dBm, SNR 5, SACCH) <000c> l1ctl.c:290 BURST IND: @(830960 = 0626/00/17) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830960 = 0626/00/17) (-108 dBm, SNR 3) <000c> l1ctl.c:290 BURST IND: @(830961 = 0626/01/18) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830961 = 0626/01/18) (-106 dBm, SNR 2) <000c> l1ctl.c:290 BURST IND: @(830962 = 0626/02/19) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830962 = 0626/02/19) (-108 dBm, SNR 3) <000c> l1ctl.c:290 BURST IND: @(830963 = 0626/03/20) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830963 = 0626/03/20) (-107 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830964 = 0626/04/21) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830964 = 0626/04/21) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830965 = 0626/05/22) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830965 = 0626/05/22) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830966 = 0626/06/23) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830966 = 0626/06/23) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830967 = 0626/07/24) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830967 = 0626/07/24) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830968 = 0626/08/25) (-107 dBm, SNR 6, UL) <000c> l1ctl.c:290 BURST IND: @(830968 = 0626/08/25) (-109 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830969 = 0626/09/26) (-101 dBm, SNR 6, UL) But it stop to capture frames, seems to be left in a standby state and I don't know why that is. With gprsdecode I can see the next image in the wireshark: http://baseband-devel.722152.n3.nabble.com/file/n3712433/wireshark-capture.png If someone knows what is the problem, please tell me. Thanks in advance. Cheers, Dani -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Sniffing-GPRS-tp3712433p3712433.html Sent from the baseband-devel mailing list archive at Nabble.com. From luca at srlabs.de Wed Feb 8 03:04:00 2012 From: luca at srlabs.de (Luca Melette) Date: Wed, 8 Feb 2012 04:04:00 +0100 Subject: Sniffing GPRS In-Reply-To: <1328257063144-3712433.post@n3.nabble.com> References: <1328257063144-3712433.post@n3.nabble.com> Message-ID: <20120208040400.2ceba408@c7h5n3o6.sofago.net> Hi Dani, > After compiling osmocom-bb and apply sylvain/burst_ind branch and > gprs_multi.patch, I execute it and try to sniff gprs traffic. > I loaded the layer1 into my C139 and I obtained an ARFCN code (883). > When I run ccch_scan -a 883 I get the next result: Your output seems OK. > But it stop to capture frames, seems to be left in a standby state > and I don't know why that is. > With gprsdecode I can see the next image in the wireshark: > > http://baseband-devel.722152.n3.nabble.com/file/n3712433/wireshark-capture.png Quite small picture, but I guess there is some version mismatch in GSMTAP constants in your wireshark. Can you please "git pull" from gprsdecode git? And tell me if the output in wireshark looks better. Also, in case of other errors, you can attach the console output of gprsdecode. Cheers, LM From dani.martinezroca at gmail.com Thu Feb 9 17:42:20 2012 From: dani.martinezroca at gmail.com (canarion) Date: Thu, 9 Feb 2012 09:42:20 -0800 (PST) Subject: Sniffing GPRS In-Reply-To: <20120208040400.2ceba408@c7h5n3o6.sofago.net> References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> Message-ID: <1328809340546-3730169.post@n3.nabble.com> Thank you. I applied the solution, but I can't be able to capture GPRS, obtaining the next output: root at bt:~/Desktop/gprs/osmocom-bb/src# ./host/layer23/src/misc/ccch_scan -a 530 Copyright (C) 2010 Harald Welte Contributions by Holger Hans Peter Freyther License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <0001> app_ccch_scan.c:105 SI1 received. <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4269931095) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202774177) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4286702193) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(872678026) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214040106539517) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3783462071) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075526476063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3414382957) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3833791687) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1409475324) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(268475078) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(939892912) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3246520066) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3850427223) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900711156) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075504876609) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3263284250) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4051765433) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075526476063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3347308031) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3263371063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3984668881) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(268475078) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202767825) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3749719268) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951101257) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4169171856) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202730769) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3330357239) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3481285555) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xaa9e80ed) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xe10b81f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075531810633) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x255783cf) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1f1181dc) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(604556062) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214072000891299) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(872678026) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4051765433) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3464558834) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x8f0883e8) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xefc90050) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3347308031) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1342251192) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4236303009) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x7310734) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xb1b280f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3263371063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3984668881) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xfa970654) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x50f783f5) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3749719268) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134639596) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951252283) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075526302987) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202730769) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xcfec80ce) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x3e74042c) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3330357239) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3515047757) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(738711998) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x2aec80e1) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xe10b81f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075531810633) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3581947292) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3464558834) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xe7c781eb) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xefc90050) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3900901519) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3498307992) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3817066073) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4236303009) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x1f2f83e3) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xb1b280f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(872886535) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380617244) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1275217371) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3867157627) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x9fa80fc) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x50f783f5) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(1409718266) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xa6a50744) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xec6f0608) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214070617536649) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075517512698) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214250001000819) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3464555727) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671523743) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3515047757) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(738711998) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3783322666) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3833642850) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951258957) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3581984922) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951151079) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1342205199) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380616628) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x970783d5) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1f2f83e3) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075507399140) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380617244) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3783522049) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3867157627) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4236311049) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1141351846) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075517512698) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3967861041) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671523743) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900911398) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3347267645) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3733188761) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214070611052851) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951258957) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671550778) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3632528289) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x520b0528) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xf6d0050) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214074612008401) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xd20e0150) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x470a83ea) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3380616628) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4068523561) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075507399140) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134788057) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380861225) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3548434234) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3967861041) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900911398) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900747386) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3967871191) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x92a580cc) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x99f083de) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075501857562) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214070611052851) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214040106836804) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671550778) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3548640369) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3364053752) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214074612008401) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x498c80c5) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x29be80f2) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075502723259) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134788057) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135830880) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380861225) <0001> app_ccch_scan.c:248 GSM48 IMM ASS (ra=0x7e, chan_nr=0x0c, HSN=59, MAIO=3, TS=4, SS=0, TSC=5) Dropping frame with 64 bit errors <000c> l1ctl.c:238 Dropping frame with 64 bit errors Dropping frame with 56 bit errors <000c> l1ctl.c:238 Dropping frame with 56 bit errors <0012> ../../../src/gsm/lapd_core.c:1452 I frame response not allowed <0012> ../../../src/gsm/lapd_core.c:383 sending MDL-ERROR-IND cause 12 <0012> ../../../src/gsm/lapdm.c:392 sending MDL-ERROR-IND 12 <0000> rslms.c:137 unknown RSLms msg_discr 0x00 <0012> ../../../src/gsm/lapd_core.c:1452 I frame response not allowed <0012> ../../../src/gsm/lapd_core.c:383 sending MDL-ERROR-IND cause 12 <0012> ../../../src/gsm/lapdm.c:392 sending MDL-ERROR-IND 12 <0000> rslms.c:137 unknown RSLms msg_discr 0x00 <0012> ../../../src/gsm/lapd_core.c:1452 I frame response not allowed <0012> ../../../src/gsm/lapd_core.c:383 sending MDL-ERROR-IND cause 12 <0012> ../../../src/gsm/lapdm.c:392 sending MDL-ERROR-IND 12 <0000> rslms.c:137 unknown RSLms msg_discr 0x00 Dropping frame with 48 bit errors Osmocom didn't create any burst file, someone know why occurs it? I've executed it on Backtrack 5 over VMWare. If someone knows what is the problem, please tell me. Thanks in advance. Cheers, Dani -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Sniffing-GPRS-tp3712433p3730169.html Sent from the baseband-devel mailing list archive at Nabble.com. From dario.lombardo at libero.it Fri Feb 17 10:43:15 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Fri, 17 Feb 2012 11:43:15 +0100 Subject: Sniffing GPRS In-Reply-To: <1328809340546-3730169.post@n3.nabble.com> References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> <1328809340546-3730169.post@n3.nabble.com> Message-ID: I'm still not able to sniff enough data to reconstruct TCP sessions. I can get datagrams (even TCP), but they look like "sparse" datagrams. Even using 2 sniffing phones I have a slightly better result, but not enough to consider it satisfying. Are there some other steps that can be done? Is there anyone, other that gprs decoder authors, able to make it completely working? Thanks. Dario. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Feb 17 10:50:25 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 17 Feb 2012 11:50:25 +0100 Subject: Sniffing GPRS In-Reply-To: References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> <1328809340546-3730169.post@n3.nabble.com> Message-ID: Hi, > I'm still not able to sniff enough data to reconstruct TCP sessions. > I can get datagrams (even TCP), but they look like "sparse" datagrams. Even > using 2 sniffing phones I have a slightly better result, but not enough to > consider it satisfying. > Are there some other steps that can be done? Sure ... debug the issue, fix it, submit a patch. You'll probably need deep knowledge of GPRS RLC/MAC layers to do that properly. > Is there anyone, other that gprs decoder authors, able to make it completely > working? I'm not even sure they do. The code is more of a "demo" than a complete system, a lot is missing to properly decode everything (for, it just "guesses" the GPRS channel from a single assignement and then listen on all timeslot of that, which mostly a short cut to grab stuff, proving it's possible but not that much more, unless the cell has only 1 GPRS arfcn). Also since it only support GPRS and not EDGE you can pretty easily miss stuff ... Cheers, Sylvain From dario.lombardo at libero.it Fri Feb 17 10:55:34 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Fri, 17 Feb 2012 11:55:34 +0100 Subject: Sniffing GPRS In-Reply-To: References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> <1328809340546-3730169.post@n3.nabble.com> Message-ID: On Fri, Feb 17, 2012 at 11:50 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > I'm still not able to sniff enough data to reconstruct TCP sessions. > > I can get datagrams (even TCP), but they look like "sparse" datagrams. > Even > > using 2 sniffing phones I have a slightly better result, but not enough > to > > consider it satisfying. > > Are there some other steps that can be done? > > Sure ... debug the issue, fix it, submit a patch. You'll probably need > deep knowledge of GPRS RLC/MAC layers to do that properly. > I do it for sure, if I am able to. > > > Is there anyone, other that gprs decoder authors, able to make it > completely > > working? > > I'm not even sure they do. > > The code is more of a "demo" than a complete system, a lot is missing > to properly decode everything (for, it just "guesses" the GPRS channel > from a single assignement and then listen on all timeslot of that, > which mostly a short cut to grab stuff, proving it's possible but not > that much more, unless the cell has only 1 GPRS arfcn). > > It would be nice to have a result like their http://srlabs.de/dl/gprs_262_80_0001_0000_20110710_2252_875_514147_0f.dat where I can find reconstructed HTTP sessions. > Also since it only support GPRS and not EDGE you can pretty easily > miss stuff ... > > That's an interesting point I can check... -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.bongiorni1 at studenti.unimi.it Fri Feb 17 11:15:32 2012 From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni) Date: Fri, 17 Feb 2012 12:15:32 +0100 Subject: Sniffing GPRS In-Reply-To: References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> <1328809340546-3730169.post@n3.nabble.com> Message-ID: Hi Dario, which is the environment that you are using for the tests? (eg. OpenBSC or a PLMN: in this case which one? 01, 10, 88) Are you trying to just sniff the air or also stimulating the traffic with your own ME? Good results depends from many factors: - If the "session" is hopping through chans or not; - If the ME supports only GPRS or not; - If you are making tests on your own lab's environment or a PLMN; - an other related with the osmocombb's ME and the cable used. In case you don't use OpenBSC with nanobts or BS-11, i would suggest use to use an old ME that supports only GPRS and not EDGE, thus u will avoid it to use EDGE's coding-schemes (eg. i obtained good results with an old gprs usb modem on PLMNs). Then i would suggest you to find an ARFCN of a PLMN that doesn't hop: i found some good ones by checking with a Blackberry's Field Test [1]. [1] http://i41.tinypic.com/20huagj.jpg Cheers, Luca > I'm still not able to sniff enough data to reconstruct TCP sessions. > I can get datagrams (even TCP), but they look like "sparse" datagrams. Even using 2 sniffing phones I have a slightly better result, but not enough to consider it satisfying. > Are there some other steps that can be done? > > Is there anyone, other that gprs decoder authors, able to make it completely working? > > Thanks. > Dario. From dario.lombardo at libero.it Fri Feb 17 11:39:50 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Fri, 17 Feb 2012 12:39:50 +0100 Subject: Sniffing GPRS In-Reply-To: References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> <1328809340546-3730169.post@n3.nabble.com> Message-ID: On Fri, Feb 17, 2012 at 12:15 PM, Luca Bongiorni < luca.bongiorni1 at studenti.unimi.it> wrote: > Hi Dario, > > which is the environment that you are using for the tests? (eg. OpenBSC or > a PLMN: in this case which one? 01, 10, 88) > PLMN > > Are you trying to just sniff the air or also stimulating the traffic with > your own ME? > stimulating > > Good results depends from many factors: > - If the "session" is hopping through chans or not; > - If the ME supports only GPRS or not; > - If you are making tests on your own lab's environment or a PLMN; > - an other related with the osmocombb's ME and the cable used. > > In case you don't use OpenBSC with nanobts or BS-11, i would suggest use > to use an old ME that supports only GPRS and not EDGE, thus u will avoid it > to use EDGE's coding-schemes (eg. i obtained good results with an old gprs > usb modem on PLMNs). Then i would suggest you to find an ARFCN of a PLMN > that doesn't hop: i found some good ones by checking with a Blackberry's > Field Test [1]. > > My stimulating ME supports edge, so my fake traffic is not good for tracking. I must find the right phone... do you have some model to suggest? I can find very old phones or very new, but it's hard to find some "medium" that support GPRS and not EDGE :). > [1] http://i41.tinypic.com/20huagj.jpg > > That sounds very interesting, since I have a BB. How can you check that your arfcn is not hopping from this menu? -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.bongiorni1 at studenti.unimi.it Fri Feb 17 13:48:41 2012 From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni) Date: Fri, 17 Feb 2012 14:48:41 +0100 Subject: Sniffing GPRS In-Reply-To: References: <1328257063144-3712433.post@n3.nabble.com> <20120208040400.2ceba408@c7h5n3o6.sofago.net> <1328809340546-3730169.post@n3.nabble.com> Message-ID: <0C3AB2A3-2949-4BBD-8A1A-823793C98737@studenti.unimi.it> Dario, > My stimulating ME supports edge, so my fake traffic is not good for tracking. I must find the right phone... do you have some model to suggest? I can find very old phones or very new, but it's hard to find some "medium" that support GPRS and not EDGE :). Just find an old one that doesn't support GPRS: phones or usb keys. > > [1] http://i41.tinypic.com/20huagj.jpg > > > That sounds very interesting, since I have a BB. How can you check that your arfcn is not hopping from this menu? As you can see on the "last GPRS TBF:" section, the only arfcn used for that session was the 983, it means that was not hopping. About how to activate the field test, just google for it. P.S.: Please reply directly on the ml. About the ARFCN allocation around Italy, is MNO related, so it could just allocate the 983 here as non-hopping and in your city as hopping one. You are on your own about checking which is the best ARFCN (non-hopping) to make tests. Cheers, Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From mad at auth.se Fri Feb 17 15:56:03 2012 From: mad at auth.se (mad) Date: Fri, 17 Feb 2012 16:56:03 +0100 Subject: Sniffing GPRS In-Reply-To: Message-ID: <20120217155603.e1fa55d3@mail.auth.se> Hi Dario, > My stimulating ME supports edge, so my fake traffic is not good for > tracking. I must find the right phone... do you have some model to suggest? > I can find very old phones or very new, but it's hard to find some "medium" > that support GPRS and not EDGE :). I would recommend you to try to get hold of an old Siemens S45, SL45 or ME45. They support only non-EDGE GPRS and have some nice monitor features available when activated (instructions are easy to find). Amongst other things it's possible to attach/detach GPRS, activate/deactivate PDP context, IP ack/unack, and so on, via menu. And using a serial cable these phones support the at+crsm-command so you have read access to TMSI, Kc and other files on the SIM during operation. Regards, Mad From dani.martinezroca at gmail.com Thu Feb 9 17:41:05 2012 From: dani.martinezroca at gmail.com (canarion) Date: Thu, 9 Feb 2012 09:41:05 -0800 (PST) Subject: Sniffing GPRS In-Reply-To: <1328257063144-3712433.post@n3.nabble.com> References: <1328257063144-3712433.post@n3.nabble.com> Message-ID: <1328809265856-3730167.post@n3.nabble.com> Thank you. I applied the solution, but I can't be able to capture GPRS, obtaining the next output: root at bt:~/Desktop/gprs/osmocom-bb/src# ./host/layer23/src/misc/ccch_scan -a 530 Copyright (C) 2010 Harald Welte Contributions by Holger Hans Peter Freyther License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <0001> app_ccch_scan.c:105 SI1 received. <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4269931095) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202774177) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4286702193) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(872678026) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214040106539517) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3783462071) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075526476063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3414382957) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3833791687) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1409475324) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(268475078) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(939892912) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3246520066) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3850427223) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900711156) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075504876609) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3263284250) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4051765433) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075526476063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3347308031) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3263371063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3984668881) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(268475078) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202767825) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3749719268) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951101257) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4169171856) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202730769) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3330357239) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3481285555) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xaa9e80ed) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xe10b81f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075531810633) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x255783cf) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1f1181dc) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(604556062) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214072000891299) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(872678026) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4051765433) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3464558834) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x8f0883e8) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xefc90050) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3347308031) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1342251192) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4236303009) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x7310734) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xb1b280f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3263371063) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3984668881) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xfa970654) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x50f783f5) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3749719268) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134639596) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951252283) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075526302987) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4202730769) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xcfec80ce) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x3e74042c) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3330357239) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3515047757) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(738711998) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x2aec80e1) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xe10b81f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075531810633) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3581947292) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3464558834) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xe7c781eb) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xefc90050) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3900901519) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3498307992) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3817066073) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4236303009) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x1f2f83e3) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xb1b280f4) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(872886535) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380617244) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1275217371) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3867157627) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x9fa80fc) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x50f783f5) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(1409718266) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xa6a50744) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xec6f0608) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214070617536649) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075517512698) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214250001000819) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3464555727) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671523743) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3515047757) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(738711998) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3783322666) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3833642850) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951258957) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3581984922) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951151079) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1342205199) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380616628) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x970783d5) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1f2f83e3) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075507399140) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380617244) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3783522049) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3867157627) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4236311049) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1141351846) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075517512698) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3967861041) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671523743) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900911398) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3347267645) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3733188761) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214070611052851) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3951258957) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671550778) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3632528289) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x520b0528) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0xf6d0050) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214074612008401) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0xd20e0150) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x470a83ea) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to tmsi M(3380616628) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4068523561) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214075507399140) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134788057) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380861225) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3548434234) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3967861041) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900911398) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3900747386) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3967871191) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x92a580cc) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x99f083de) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075501857562) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214070611052851) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214040106836804) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(671550778) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3548640369) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3364053752) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214074612008401) <0001> app_ccch_scan.c:451 PAGING of type 3 is not implemented. <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x498c80c5) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x29be80f2) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214075502723259) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134788057) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135830880) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3380861225) <0001> app_ccch_scan.c:248 GSM48 IMM ASS (ra=0x7e, chan_nr=0x0c, HSN=59, MAIO=3, TS=4, SS=0, TSC=5) Dropping frame with 64 bit errors <000c> l1ctl.c:238 Dropping frame with 64 bit errors Dropping frame with 56 bit errors <000c> l1ctl.c:238 Dropping frame with 56 bit errors <0012> ../../../src/gsm/lapd_core.c:1452 I frame response not allowed <0012> ../../../src/gsm/lapd_core.c:383 sending MDL-ERROR-IND cause 12 <0012> ../../../src/gsm/lapdm.c:392 sending MDL-ERROR-IND 12 <0000> rslms.c:137 unknown RSLms msg_discr 0x00 <0012> ../../../src/gsm/lapd_core.c:1452 I frame response not allowed <0012> ../../../src/gsm/lapd_core.c:383 sending MDL-ERROR-IND cause 12 <0012> ../../../src/gsm/lapdm.c:392 sending MDL-ERROR-IND 12 <0000> rslms.c:137 unknown RSLms msg_discr 0x00 <0012> ../../../src/gsm/lapd_core.c:1452 I frame response not allowed <0012> ../../../src/gsm/lapd_core.c:383 sending MDL-ERROR-IND cause 12 <0012> ../../../src/gsm/lapdm.c:392 sending MDL-ERROR-IND 12 <0000> rslms.c:137 unknown RSLms msg_discr 0x00 Dropping frame with 48 bit errors Osmocom didn't create any burst file, someone know why occurs it? I've executed it on Backtrack 5 over VMWare. If someone knows what is the problem, please tell me. Thanks in advance. Cheers, Dani -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Sniffing-GPRS-tp3712433p3730167.html Sent from the baseband-devel mailing list archive at Nabble.com. From einzeln00 at gmail.com Fri Feb 3 10:56:16 2012 From: einzeln00 at gmail.com (Jerry Giant) Date: Fri, 3 Feb 2012 18:56:16 +0800 Subject: develop a software radio front end Message-ID: Proposal to develop a software front end Hi, list. --Intro: After watching ccc camp videos, I bought myself a moto c118 and run the Osmocom-bb software on it. It's great fun to get a free software running on proprietary hardware, and so much could be learned from the source code. But what to do when the gray market stock sold out, or some one want to pick up the task of implementing the hardware in a open source fashion? OpenBTS used USRP to implement its radio, but USRP is aged, and it's documentation and price is not so friendly as I see. If further sub projects of osmocom matured, still we have to stick on the hacking hardware would not be so fun. To better the integrity and usefulness of the whole project, we can design and build a software radio front end for osmocom project. Interested? --Background: I am a Chinese electronic engineer working at small company in China, working on machine vision, now our product is building a FPGA/TI DSP based embedded device. I have some free time to learn and very interested in build a software radio front end. --Initial Thought: The goal of build a Osmocom Software Radio Kit, is to build a multipurpose radio front end which compatible to All or Most air interfaces now osmocom is interested. Interfacing an emulated Calypso DSP interface is way to reuse the code, or build another L1 dedicated for OSRK is an option. The hardware spec could be much better than USRP as vendor's products line evolved, but OSRK better to be mobile, has modular RF power amplifier interface, and battery powered. --Hardware Specification: Let get started. From pabs3 at bonedaddy.net Fri Feb 3 11:33:35 2012 From: pabs3 at bonedaddy.net (Paul Wise) Date: Fri, 3 Feb 2012 19:33:35 +0800 Subject: develop a software radio front end In-Reply-To: References: Message-ID: Perhaps you would be interested in OsmoSDR: http://sdr.osmocom.org/trac/ -- bye, pabs From laforge at gnumonks.org Fri Feb 3 14:15:11 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 3 Feb 2012 15:15:11 +0100 Subject: develop a software radio front end In-Reply-To: References: Message-ID: <20120203141511.GA9030@prithivi.gnumonks.org> Hi Jerry, On Fri, Feb 03, 2012 at 06:56:16PM +0800, Jerry Giant wrote: > Proposal to develop a software front end thanks a lot for proposing to build a SDR frontend for Osmocom and/or other FOSS communications projects. However, on my experience, there is much more hardware available than there is good SDR softmodem / PHY implementations for the various protocols. As for hardware, there is Funcube Dongle, the various USRP versions, the various "USRP like" clones from India and China, UmTRX is being built, GAPfiller, and last but not least OsmoSDR. What's much harder thna getting some SDR hardware is getting good, reliable PHY layer implementations for the various communications systems. OpenBTS exists for the GSM Base Station side. airprobe is much inferior and can do Rx only. OsmocomTETRA and OsmocomGMR are both receive-only. So I would think engineering time is much more required in terms of building full rx/tx PHY layers for the various systems, from GSM (MS-side), UMTS/WCDMA (MS and BS side) or even other systems like TETRA, GMR, etc. I understand you are an electronics engineer and not a software developer, so I could understand if think working primarily on those PHY implementations would not be good use of your time... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas at eversberg.eu Fri Feb 3 16:39:51 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 03 Feb 2012 17:39:51 +0100 Subject: Operator name in cell_log log file In-Reply-To: References: Message-ID: <4F2C0DD7.60803@eversberg.eu> Dario Lombardo wrote: > Why doesn't cell_log write the operator name in its log file? Is there > any issue related to it? > Attached a patch to log operator name and country. > Dario. hi dario, the reason for that is that cell_log only logs the raw data. later it can be decoded (e.g. by gsmmap tool) with all the info you like. decoding things like "operator" could lead to the following problems when they are stored in the log file: - operator names may change - list of operators may have wrong names or is incomplete - decoding functions may have bugs, so they might output wrong results - decoding several informations would inflate the log file - someone using the log file may not care about operator names in the past we had a bug in the frequency list decoder. after i fixed it, i just parsed my log file again and got the right frequencies. if you need to know what operators you have in your log, i suggest to write a tool that parses the log file and outputs a list of operator infos and other infos you like. look at "gsmmap" to see how it is done. regards, andreas From vogelchr at vogel.cx Sun Feb 5 13:50:55 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 5 Feb 2012 14:50:55 +0100 Subject: Patch: Automatically run osmoload from osmocon Message-ID: <20120205135052.GA9738@vogel.cx> Hi, I'm getting kind of annoyed by the new >64k firmwares that need to be loaded via osmoload. Included patch #2 adds a "-a" option to osmocon that runs an arbitrary script after the main firmware has been successfully uploaded to the phone. This script could, for example, then handle upload of a second stage firmware via osmoload. Also layer23 could be started here just before uploading layer1. The script will be given the socket, serial port, loader method (c123xor...) and main firmware as arguments, those can be used to distinguish several phones that are connected to the same PC. Example usage (using attached osmoload.sh script): osmocon -p /dev/ttyUSB0 -m c155 -a .../osmoload.sh \ .../board/compal_e99/loader.compalram.bin Received DOWNLOAD ACK from phone, your code is running now! OSMOCOM Loader (revision osmocon_v0.0.0-1299-g7c08201) (---- 2 second delay ----) [osmoload.sh] Socket is /tmp/osmocom_loader, port is /dev/ttyUSB0. [osmoload.sh] Loader method was c155. [osmoload.sh] New firmware will be osmocom-bb/src/target/firmware/board/compal_e99/rssi.highram.bin. Received pong. Loading 75472 bytes of memory to address 0x820000 from file osmocom-bb/src/target/firmware/board/compal_e99/rssi.highram.bin .................................................................. Chris From vogelchr at vogel.cx Sun Feb 5 13:01:17 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 5 Feb 2012 14:01:17 +0100 Subject: [PATCH 1/2] osmocon: array of download-method names Message-ID: An array of method names for the parser methods (c123xor, mtk, ...) has been introduced, so that we can easily convert back and forth. --- src/host/osmocon/osmocon.c | 39 ++++++++++++++++++++++++--------------- 1 files changed, 24 insertions(+), 15 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index fc29506..b3eaedb 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -126,6 +126,16 @@ enum dnload_mode { MODE_INVALID, }; +const char * const dnload_mode_str[]={ + [MODE_C123]="c123", + [MODE_C123xor]="c123xor", + [MODE_C140]="c140", + [MODE_C140xor]="c140xor", + [MODE_C155]="c155", + [MODE_ROMLOAD]="romload", + [MODE_MTK]="mtk", +}; + struct dnload { enum dnload_state state; enum romload_state romload_state; @@ -1170,24 +1180,21 @@ static int serial_read(struct osmo_fd *fd, unsigned int flags) static int parse_mode(const char *arg) { - if (!strcasecmp(arg, "c123")) - return MODE_C123; - else if (!strcasecmp(arg, "c123xor")) - return MODE_C123xor; - else if (!strcasecmp(arg, "c140")) - return MODE_C140; - else if (!strcasecmp(arg, "c140xor")) - return MODE_C140xor; - else if (!strcasecmp(arg, "c155")) - return MODE_C155; - else if (!strcasecmp(arg, "romload")) - return MODE_ROMLOAD; - else if (!strcasecmp(arg, "mtk")) - return MODE_MTK; + int i; + for(i=0;i= MODE_INVALID) + return "invalid"; + return dnload_mode_str[mode]; +} + #define HELP_TEXT \ "[ -v | -h ] [ -d [t][r] ] [ -p /dev/ttyXXXX ]\n" \ "\t\t [ -s /tmp/osmocom_l2 ]\n" \ @@ -1414,8 +1421,10 @@ int main(int argc, char **argv) break; case 'm': dnload.mode = parse_mode(optarg); - if (dnload.mode == MODE_INVALID) + if (dnload.mode == MODE_INVALID){ + fprintf(stderr,"Invalid download mode!\n"); usage(argv[0]); + } break; case 's': layer2_un_path = optarg; -- 1.7.0.4 --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-osmocon-Option-a-runs-program-script-on-upload.patch" From vogelchr at vogel.cx Sun Feb 5 13:33:26 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 5 Feb 2012 14:33:26 +0100 Subject: [PATCH 2/2] osmocon: Option -a runs program/script on upload Message-ID: The program option "-a program" runs the specified program or script after a ACK from the phone has been received. This can be used to trigger uploading the second-stage firmware with osmoload after the osmocom loader has successfully been run on the phone. --- src/host/osmocon/osmocon.c | 76 ++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 74 insertions(+), 2 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index b3eaedb..eefbed2 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -178,6 +179,19 @@ struct dnload { static struct dnload dnload; static struct osmo_timer_list tick_timer; +/* Information needed for callback on successful program upload to mobile. + * Only active if ack_prog_info.progname != NULL. */ + +#define ACK_PROG_TIMER_DELAY 2000000 +static struct osmo_timer_list ack_prog_timer; +struct ack_prog_info { + char *progname; + char *sockname; + char *serialdev; + char * const *envp; +}; +static struct ack_prog_info ack_prog_info = { NULL }; + /* Compal ramloader specific */ static const uint8_t phone_prompt1[] = { 0x1b, 0xf6, 0x02, 0x00, 0x41, 0x01, 0x40 }; static const uint8_t dnload_cmd[] = { 0x1b, 0xf6, 0x02, 0x00, 0x52, 0x01, 0x53 }; @@ -823,6 +837,9 @@ static int handle_read(void) dnload.write_ptr = dnload.data; dnload.expect_hdlc = 1; + if(ack_prog_info.progname) + osmo_timer_schedule(&ack_prog_timer,0,ACK_PROG_TIMER_DELAY); + /* check for romloader chainloading mode used as a workaround * for the magic on the C139/C140 and J100i */ if (dnload.chainload_filename != NULL) { @@ -1202,6 +1219,7 @@ dnload_mode_to_str(enum dnload_mode mode){ "\t\t [ -m {c123,c123xor,c140,c140xor,c155,romload,mtk} ]\n" \ "\t\t [ -c /to-be-chainloaded-file.bin ]\n" \ "\t\t [ -i beacon-interval (mS) ]\n" \ + "\t\t [ -a program-to-be-run-after-upload-ack ]\n" \ "\t\t file.bin\n\n" \ "* Open serial port /dev/ttyXXXX (connected to your phone)\n" \ "* Perform handshaking with the ramloader in the phone\n" \ @@ -1401,7 +1419,46 @@ void parse_debug(const char *str) } } -int main(int argc, char **argv) +/* timer callback function that gets triggered after ACK + * for successful program upload has been received from the phone + */ + +void +ack_prog_callback(void *p) +{ + pid_t chld; + char *argv[]={ + ack_prog_info.progname, + ack_prog_info.sockname, + ack_prog_info.serialdev, + (char*)dnload_mode_str[dnload.mode], + dnload.filename, + NULL + }; + int i; + + signal(SIGCHLD,SIG_IGN); + + if((chld=fork()) != 0){ /* ---- in parent ---- */ + if(chld == -1) + perror("fork()"); + else + fprintf(stderr,"Running %s on ack.\n", + ack_prog_info.progname); + return; + }; + + /* ---- in child ---- */ + for(i=3;i<1024;i++) + close(i); + + execve(ack_prog_info.progname,argv,ack_prog_info.envp); + perror(ack_prog_info.progname); + exit(1); +} + +int +main(int argc, char **argv,char **envp) { int opt, flags; uint32_t tmp_load_address = ROMLOAD_ADDRESS; @@ -1414,7 +1471,7 @@ int main(int argc, char **argv) dnload.previous_filename = NULL; dnload.beacon_interval = DEFAULT_BEACON_INTERVAL; - while ((opt = getopt(argc, argv, "d:hl:p:m:c:s:i:v")) != -1) { + while ((opt = getopt(argc, argv, "d:hl:p:m:c:s:i:va:")) != -1) { switch (opt) { case 'p': serial_dev = optarg; @@ -1444,6 +1501,9 @@ int main(int argc, char **argv) case 'i': dnload.beacon_interval = atoi(optarg) * 1000; break; + case 'a': + ack_prog_info.progname = optarg; + break; case 'h': default: usage(argv[0]); @@ -1451,12 +1511,23 @@ int main(int argc, char **argv) } } + if (argc <= optind) { dnload.filename = NULL; } else { dnload.filename = argv[optind]; } + if(ack_prog_info.progname){ + fprintf(stderr,"Will run %s on successful upload.\n", + ack_prog_info.progname); + ack_prog_info.sockname = (char*)loader_un_path; + ack_prog_info.serialdev = serial_dev; + ack_prog_info.envp = envp; + ack_prog_timer.cb = ack_prog_callback; + ack_prog_timer.data = &ack_prog_info; + } + dnload.serial_fd.fd = osmo_serial_init(serial_dev, MODEM_BAUDRATE); if (dnload.serial_fd.fd < 0) { fprintf(stderr, "Cannot open serial device %s\n", serial_dev); @@ -1520,3 +1591,4 @@ int main(int argc, char **argv) exit(0); } + -- 1.7.0.4 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="osmoload_sh.txt" #!/bin/bash socket="$1" port="$2" method="$3" main_fw="$4" fw_dir="${main_fw%/*}" new_fw="${fw_dir}/rssi.highram.bin" osmoload="$OSMOCOM_ROOT/osmocom-bb/src/host/osmocon/osmoload" tag="[${0##*/}]" echo "Environment:" env if ! [ -x "$osmoload" ] ; then echo "$tag *** $osmoload not found/not executable." >&2 exit 1 fi if ! [ -f "$new_fw" ] ; then echo "$tag *** $new_fw not found." >&2 exit 1 fi echo "$tag Socket is $socket, port is $port." >&2 echo "$tag Loader method was $method." >&2 echo "$tag New firmware will be $new_fw." >&2 MAX_PINGS=5 N=0 while [ "$N" -lt "$MAX_PINGS" ] ; do N="$(( $N + 1 ))" $osmoload -l $socket ping if [ "$?" == 0 ] ; then break fi done if [ "$N" -ge $MAX_PINGS ] ; then echo "$tag *** could not ping phone!" >&2 exit 1 fi $osmoload -l $socket memload 0x820000 $new_fw if [ "$?" != 0 ] ; then echo "$tag *** could not upload firmware!" >&2 exit 1 fi $osmoload -l $socket jump 0x820000 if [ "$?" != 0 ] ; then echo "$tag *** could not run firmware!" >&2 exit 1 fi --X1bOJ3K7DJ5YkBrT-- From mad at auth.se Sun Feb 5 15:24:40 2012 From: mad at auth.se (mad) Date: Sun, 05 Feb 2012 16:24:40 +0100 Subject: Patch: Automatically run osmoload from osmocon In-Reply-To: <20120205135052.GA9738@vogel.cx> Message-ID: <20120205152440.eb837007@mail.auth.se> Hi Christian, you are aware of the possibility of chainloading these firmwares using osmocon with removed 64k check as Steve described in http://lists.osmocom.org/pipermail/baseband-devel/2012-January/002694.html ? Otherwise it's not a bad idea of being able to start some script after successful firmware upload. Regards, Mad From vogelchr at vogel.cx Sun Feb 5 15:56:11 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 5 Feb 2012 16:56:11 +0100 Subject: Patch: Automatically run osmoload from osmocon In-Reply-To: <20120205152440.eb837007@mail.auth.se> References: <20120205135052.GA9738@vogel.cx> <20120205152440.eb837007@mail.auth.se> Message-ID: <20120205155611.GA10010@vogel.cx> Hi, On Sun, Feb 05, 2012 at 04:24:40PM +0100, mad wrote: > you are aware of the possibility of chainloading these firmwares using osmocon > with removed 64k check as Steve described in > http://lists.osmocom.org/pipermail/baseband-devel/2012-January/002694.html ? > Otherwise it's not a bad idea of being able to start some script after successful firmware upload. I am aware, but for whatever reason it only worked with one of my phones (C155 or C123, I forgot). Osmoload worked all the time. Chris From tyruskam at gmail.com Tue Feb 7 10:05:04 2012 From: tyruskam at gmail.com (ty) Date: Tue, 7 Feb 2012 13:05:04 +0300 Subject: USSD Traffic analysis Message-ID: Hallo all. I have been playing around with OsmoscomBB for GSM voice traffic and capture. My interested has now stemmed into USSD traffic. Whenever I initiate a ussd session, I get the error "Session Terminated". Has anyone attempted to capture ussd sessions using the Motorola C123 or do I need specialized equipment for this? Also, am looking into researching more into ussd because here in Africa, specifically Kenya, there is a proliferation of financial services over USSD and this begs the question just how secure is it? If anyone on the list might have done a bit of digging around I'd really love to share learnings and insights. -ty -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Feb 7 12:11:44 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 7 Feb 2012 13:11:44 +0100 Subject: USSD Traffic analysis In-Reply-To: References: Message-ID: <20120207121144.GL947@prithivi.gnumonks.org> Hi! On Tue, Feb 07, 2012 at 01:05:04PM +0300, ty wrote: > specifically Kenya, there is a proliferation of financial services over > USSD and this begs the question just how secure is it? If anyone on the > list might have done a bit of digging around I'd really love to share > learnings and insights. Typically those mobile payment applications are SIM application toolkit based and the SIM card uses encrypted SMS to talk to the back-end server. So assuming that the crypto was done properly, there's nothing wrong with such an architecture. There are some services that use USSD, but then you can only transfer between accounts that you have previously authorized to be used this way using a more secure transport channel. Typically people list only their own account to transfer between prepaid and bank account this way, so the fraud potential seems limited. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From tyruskam at gmail.com Tue Feb 7 12:18:46 2012 From: tyruskam at gmail.com (ty) Date: Tue, 7 Feb 2012 15:18:46 +0300 Subject: USSD Traffic analysis In-Reply-To: <20120207121144.GL947@prithivi.gnumonks.org> References: <20120207121144.GL947@prithivi.gnumonks.org> Message-ID: Thanks for your insight Harald. I work for one of the leading mcommerce providers in the country as a security analyst and from the architectures, yes all the transactions take place via secure channels. However, my concern has always been after the transaction leaves the application and is handed over to the USSD gateway for the MNO, is it possible at an SS7 layer to intercept the said traffic? I haven't seen any research into how USSD can be intercepted OTA just like GSM voice calls have been intercepted. Your thoughts are highly appreciated -ty On Tue, Feb 7, 2012 at 3:11 PM, Harald Welte wrote: > Hi! > > On Tue, Feb 07, 2012 at 01:05:04PM +0300, ty wrote: > > specifically Kenya, there is a proliferation of financial services over > > USSD and this begs the question just how secure is it? If anyone on the > > list might have done a bit of digging around I'd really love to share > > learnings and insights. > > Typically those mobile payment applications are SIM application toolkit > based and the SIM card uses encrypted SMS to talk to the back-end > server. So assuming that the crypto was done properly, there's nothing > wrong with such an architecture. > > There are some services that use USSD, but then you can only transfer > between accounts that you have previously authorized to be used this way > using a more secure transport channel. Typically people list only their > own account to transfer between prepaid and bank account this way, so > the fraud potential seems limited. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Feb 7 15:14:04 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 7 Feb 2012 16:14:04 +0100 Subject: USSD Traffic analysis In-Reply-To: References: <20120207121144.GL947@prithivi.gnumonks.org> Message-ID: <20120207151404.GP947@prithivi.gnumonks.org> Hi Ty, On Tue, Feb 07, 2012 at 03:18:46PM +0300, ty wrote: > I work for one of the leading mcommerce providers in the country as a > security analyst and from the architectures, yes all the transactions take > place via secure channels. However, my concern has always been after the > transaction leaves the application and is handed over to the USSD gateway > for the MNO, is it possible at an SS7 layer to intercept the said traffic? There is nothing specific to USSD here. It's a MAP transaction, encapsulated in TCAP+SCCP+MTP3 or any of the SIGTRAN variants. So the question is basically a general question on SS7/SCCP security, and thus off-topic on this list, which is about OsmocomBB baseband development and not core network technology. > I haven't seen any research into how USSD can be intercepted OTA just like > GSM voice calls have been intercepted. USSD is transported on a signallign channel like SMS or call control. Thre is no difference in terms of intercepting or MITM from voice/SMS. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Feb 7 23:29:20 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 8 Feb 2012 00:29:20 +0100 Subject: libosmocore re-sync Message-ID: <20120207232920.GE2286@prithivi.gnumonks.org> FYI, I have committed a 'git-subtree' update of libosmocore to osmocom-bb earlier today. It seemed non-intrusive to me, as most of the changes were in testing and gsm 08.08 code, both of which are not used in the ARM-target builds. Nonetheless, if you experience strange new problems, the libosmocore update might be a possible cause. The update was required due to a __attribute((packed)) fix by Andreas to some GSM 04.08 structures... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dario.lombardo at libero.it Wed Feb 8 12:32:59 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Wed, 8 Feb 2012 13:32:59 +0100 Subject: Can't compile after last pull Message-ID: I've pulled git repo today, but the RSSI firmware gets an error. apps/rssi/main.c: In function `main': apps/rssi/main.c:896: warning: 'a' might be used uninitialized in this function apps/rssi/main.c:896: warning: 'e' might be used uninitialized in this function CC board/compal_e88/rssi.compalram.manifest.o LD board/compal_e88/rssi.compalram.elf OBJ board/compal_e88/rssi.compalram.bin CC board/compal_e88/rssi.highram.manifest.o LD board/compal_e88/rssi.highram.elf OBJ board/compal_e88/rssi.highram.bin CC board/compal_e88/rssi.e88loader.manifest.o LD board/compal_e88/rssi.e88loader.elf OBJ board/compal_e88/rssi.e88loader.bin CC board/compal_e88/rssi.e88flash.manifest.o LD board/compal_e88/rssi.e88flash.elf OBJ board/compal_e88/rssi.e88flash.bin CC board/compal_e86/rssi.compalram.manifest.o LD board/compal_e86/rssi.compalram.elf arm-elf-ld: region LRAM is full (board/compal_e86/rssi.compalram.elf section .data) make[1]: *** [board/compal_e86/rssi.compalram.elf] Error 1 make[1]: Leaving directory src/target/firmware' make: *** [firmware] Error 2 $ git pull Already up-to-date. $ Anyone experiencing the same issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lei5xai6guCeeG3o at tormail.net Thu Feb 9 06:41:56 2012 From: Lei5xai6guCeeG3o at tormail.net (User) Date: Wed, 8 Feb 2012 22:41:56 -0800 (PST) Subject: Can't compile after last pull In-Reply-To: References: Message-ID: <1328769716758-3728600.post@n3.nabble.com> Dario Lombardo wrote > > arm-elf-ld: region LRAM is full (board/compal_e86/rssi.compalram.elf > section .data) > make[1]: *** [board/compal_e86/rssi.compalram.elf] Error 1 > make[1]: Leaving directory src/target/firmware' > make: *** [firmware] Error 2 > > Anyone experiencing the same issue? > I've got the same error (if TX is enabled) -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Can-t-compile-after-last-pull-tp3725729p3728600.html Sent from the baseband-devel mailing list archive at Nabble.com. From steve at steve-m.de Thu Feb 9 12:44:28 2012 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 09 Feb 2012 13:44:28 +0100 Subject: Can't compile after last pull In-Reply-To: <1328769716758-3728600.post@n3.nabble.com> References: <1328769716758-3728600.post@n3.nabble.com> Message-ID: <4F33BFAC.3020106@steve-m.de> Hi, On 09.02.2012 07:41, User wrote: >> Anyone experiencing the same issue? It seems your toolchain produces a binary larger than 80 kBytes (0x14000), which is the current limit for compalram images. What we need is a setting in the Makefile to blacklist certain apps from being built for certain environments, but what you can do for now is increase the LRAM length and adjust the IRAM ORIGIN in firmware/board /compal/ram.lds. Regards, Steve From andreas at eversberg.eu Thu Feb 9 13:56:01 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 09 Feb 2012 14:56:01 +0100 Subject: Can't compile after last pull In-Reply-To: <4F33BFAC.3020106@steve-m.de> References: <1328769716758-3728600.post@n3.nabble.com> <4F33BFAC.3020106@steve-m.de> Message-ID: <4F33D071.8090304@eversberg.eu> Steve Markgraf wrote: > Hi, > > On 09.02.2012 07:41, User wrote: > > >>> Anyone experiencing the same issue? >>> > It seems your toolchain produces a binary larger than 80 kBytes > (0x14000), which is the current limit for compalram images. > > What we need is a setting in the Makefile to blacklist certain apps > from being built for certain environments, but what you can do for now > is increase the LRAM length and adjust the IRAM ORIGIN in firmware/board > /compal/ram.lds. > > Regards, > Steve > would it be possible to make a linker script that dynamically sets code and data memory size? From dario.lombardo at libero.it Fri Feb 10 09:06:19 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Fri, 10 Feb 2012 10:06:19 +0100 Subject: Can't compile after last pull In-Reply-To: <4F33BFAC.3020106@steve-m.de> References: <1328769716758-3728600.post@n3.nabble.com> <4F33BFAC.3020106@steve-m.de> Message-ID: I've tried this: MEMORY { /* compal-loaded binary: our text, initialized data */ LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00015000 /* compal-loaded binary: our unitialized data, stacks, heap */ IRAM (rw) : ORIGIN = 0x00815000, LENGTH = 0x0000c000 } but LD board/compal_e88/rssi.compalram.elf OBJ board/compal_e88/rssi.compalram.bin LD board/compal_e86/rssi.compalram.elf OBJ board/compal_e86/rssi.compalram.bin LD board/compal_e86/rssi.highram.elf arm-elf-ld: region LRAM is full (board/compal_e86/rssi.highram.elf section .data) arm-elf-ld: section .got [00820000 -> 00820013] overlaps section .text.start [00820000 -> 0082006b] make: *** [board/compal_e86/rssi.highram.elf] Error 1 I have the same behaviour also with other values of length/origin. Any other suggestion? On Thu, Feb 9, 2012 at 1:44 PM, Steve Markgraf wrote: > Hi, > > On 09.02.2012 07:41, User wrote: > > >> Anyone experiencing the same issue? > > It seems your toolchain produces a binary larger than 80 kBytes > (0x14000), which is the current limit for compalram images. > > What we need is a setting in the Makefile to blacklist certain apps > from being built for certain environments, but what you can do for now > is increase the LRAM length and adjust the IRAM ORIGIN in firmware/board > /compal/ram.lds. > > Regards, > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juantxipazos at yahoo.es Mon Feb 13 04:46:16 2012 From: juantxipazos at yahoo.es (Juantxi) Date: Mon, 13 Feb 2012 05:46:16 +0100 Subject: rare warning? References: <1328769716758-3728600.post@n3.nabble.com><4F33BFAC.3020106@steve-m.de> Message-ID: <86EA6AE662264783ACE1DA96AF3BD046@Maite> make[1]: warning: Clock skew detected. Your build may be incomplete. CygWin git.February thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Feb 14 01:19:43 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Feb 2012 02:19:43 +0100 Subject: rare warning? In-Reply-To: <86EA6AE662264783ACE1DA96AF3BD046@Maite> References: <86EA6AE662264783ACE1DA96AF3BD046@Maite> Message-ID: <20120214011943.11511.qmail@stuge.se> Juantxi wrote: > make[1]: warning: Clock skew detected. Your build may be incomplete. Your system clock has been adjusted backwards. Some files have dates in the future. //Peter From juantxipazos at yahoo.es Sun Feb 12 23:30:37 2012 From: juantxipazos at yahoo.es (Juantxi) Date: Mon, 13 Feb 2012 00:30:37 +0100 Subject: rare warning? References: <86EA6AE662264783ACE1DA96AF3BD046@Maite> <20120214011943.11511.qmail@stuge.se> Message-ID: <9E90DACFBE704641B8230D170CBF157E@Maite> thank you ----- Original Message ----- From: "Peter Stuge" To: Sent: Tuesday, February 14, 2012 2:19 AM Subject: Re: rare warning? > Juantxi wrote: >> make[1]: warning: Clock skew detected. Your build may be incomplete. > > Your system clock has been adjusted backwards. Some files have dates > in the future. > > > //Peter > From Lei5xai6guCeeG3o at tormail.net Mon Feb 13 08:06:18 2012 From: Lei5xai6guCeeG3o at tormail.net (-) Date: Mon, 13 Feb 2012 00:06:18 -0800 (PST) Subject: Can't compile after last pull In-Reply-To: References: <1328769716758-3728600.post@n3.nabble.com> <4F33BFAC.3020106@steve-m.de> Message-ID: <1329120378294-3739436.post@n3.nabble.com> Now it works. I've tried this: I changed ram.lds & highram.lds. ram.lds: LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00015000 IRAM (rw) : ORIGIN = 0x00815000, LENGTH = 0x0000c000 highram.lds: LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00015000 IRAM (rw) : ORIGIN = 0x00835000, LENGTH = 0x0000c000 -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Can-t-compile-after-last-pull-tp3725729p3739436.html Sent from the baseband-devel mailing list archive at Nabble.com. From osmocom at ehlers.info Sat Feb 11 21:19:25 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sat, 11 Feb 2012 22:19:25 +0100 (CET) Subject: changing key as security feature in osmocom? Message-ID: Hi, I just saw the talk of Karsten Nohl at 28C3 and ask myself if it would be possible to trigger a new session key (KC) after every e.g. Call,SMS,USSD and silent SMS :) for next event. I mean it seems that e.g. in O2 Network in germany the key never changes, only when turning off and on the phone and after many events. For O2 it maybe enough to reconnect to the network? I really would like to get a somewhat secure GSM connection for my anchor mobile at home (remotely controlled from the PC) for my nationwide homezone (BWHZ), using osmocombb. :) Has anyone a suggestion, idea? Thanks Tim From 246tnt at gmail.com Sat Feb 11 21:32:45 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 11 Feb 2012 22:32:45 +0100 Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: > Has anyone a suggestion, idea? Transmit '7' as the key sequence number. This tells the network there is no valid Kc in the SIM, so the network will issue a new AUTH REQ to get a new Kc. Cheers, Sylvain From osmocom at ehlers.info Sat Feb 11 21:49:13 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sat, 11 Feb 2012 22:49:13 +0100 (CET) Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: On Sat, 11 Feb 2012, Sylvain Munaut wrote: >> Has anyone a suggestion, idea? > > Transmit '7' as the key sequence number. This tells the network there > is no valid Kc in the SIM, so the network will issue a new AUTH REQ to > get a new Kc. ok, perfect, thanks. If nobody has implemented something like that, I will try that next week. But maybe somebody (maybe you :)) is deep enough in the code, to easily find the place to put that in? Cheers Tim From 246tnt at gmail.com Sat Feb 11 22:22:23 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 11 Feb 2012 23:22:23 +0100 Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: > But maybe somebody (maybe you :)) is deep enough in the code, to easily find > the place to put that in? This is more Andreas' area of expertise. However a quick grep on "key_seq" would get your started. I guess you'd need: - Add a vty option for it - Add a 'subscr_get_key_seq' helper that either returns the real one or force 7 if the privacy option is set - Replace direct subscr->key_seq access by this helper in each of the 3 possible initial messages : gsm48_mm_tx_loc_upd_req, gsm48_mm_tx_cm_serv_req, gsm48_rr_dl_est (in the paging response creation) Cheers, Sylvain From osmocom at ehlers.info Sun Feb 12 19:28:18 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 12 Feb 2012 20:28:18 +0100 (CET) Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: On Sat, 11 Feb 2012, Sylvain Munaut wrote: Hi Sylvain, > I guess you'd need: > > - Add a vty option for it > - Add a 'subscr_get_key_seq' helper that either returns the real one > or force 7 if the privacy option is set > - Replace direct subscr->key_seq access by this helper in each of the > 3 possible initial messages : > gsm48_mm_tx_loc_upd_req, gsm48_mm_tx_cm_serv_req, gsm48_rr_dl_est > (in the paging response creation) wow, thank you so much for directing me. I made the attached patch. For USSD it is really working. I didn't test more. So if you would be so kind, could you check if every event is covered now (especially things like silent SMS; I don't know how to test that)? And if so, would you commit the patch in the git? Cheers and thanks Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: force_key.patch Type: text/x-patch Size: 4842 bytes Desc: URL: From 246tnt at gmail.com Sun Feb 12 19:36:09 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 12 Feb 2012 20:36:09 +0100 Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: Hi, > I made the attached patch. For USSD it is really working. I didn't test > more. So if you would be so kind, could you check if every event is covered > now (especially things like silent SMS; I don't know how to test that)? Silent SMS are just like normal SMS ... > And if so, would you commit the patch in the git? Please make sure you indent everything with TABs. Once you fix that and resend I think it'll be OK. But I'll let Andreas look at it and commit it since it's own code. Cheers, Sylvain From 246tnt at gmail.com Sun Feb 12 19:38:10 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 12 Feb 2012 20:38:10 +0100 Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: Oh, I also just noticed : you should probably declare int subscr_get_key_seq(struct osmocom_ms *ms, struct gsm_subscriber *subscr); somewhre in a .h ... Cheers, Sylvain From osmocom at ehlers.info Sun Feb 12 19:57:35 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 12 Feb 2012 20:57:35 +0100 (CET) Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: On Sun, 12 Feb 2012, Sylvain Munaut wrote: Hi Sylvain, > Silent SMS are just like normal SMS ... ok, SMS is working, just checked. > Please make sure you indent everything with TABs. > > Once you fix that and resend I think it'll be OK. But I'll let Andreas > look at it and commit it since it's own code. > > Oh, I also just noticed : you should probably declare > int subscr_get_key_seq(struct osmocom_ms *ms, struct gsm_subscriber *subscr); > somewhre in a .h ... I hope its ok now. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: force_key.patch Type: text/x-patch Size: 5441 bytes Desc: URL: From 246tnt at gmail.com Sun Feb 12 20:08:15 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 12 Feb 2012 21:08:15 +0100 Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: Hi, Actually, I have a couple more points: * why declare it in networks.h ? there is a subscriber.h which seem more appropriate * I would actually call it gsm_subscr_get_key_seq , it seems to be the convention of that file for exported functions * The convention for vty commands uses '-' instead of '_', so call it "force-key" rather than "force_key" * Actually maybe call if "force-rekey" everywhere (vty, variable name, ...) since this seems more decriptive (you don't force the key, you force the negotiation of a new key) @Andreas: Do you see anything else ? Cheers, Sylvain From osmocom at ehlers.info Sun Feb 12 20:41:02 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 12 Feb 2012 21:41:02 +0100 (CET) Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: On Sun, 12 Feb 2012, Sylvain Munaut wrote: Hi Sylvain, > Actually, I have a couple more points: > > * why declare it in networks.h ? there is a subscriber.h which seem > more appropriate > * I would actually call it gsm_subscr_get_key_seq , it seems to be > the convention of that file for exported functions > * The convention for vty commands uses '-' instead of '_', so call it > "force-key" rather than "force_key" > * Actually maybe call if "force-rekey" everywhere (vty, variable name, > ...) since this seems more decriptive (you don't force the key, you > force the negotiation of a new key) ok, I hope its correct and conventional now. Cheers Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: force_rekey.patch Type: text/x-patch Size: 5490 bytes Desc: URL: From andreas at eversberg.eu Mon Feb 13 06:56:16 2012 From: andreas at eversberg.eu (jolly) Date: Mon, 13 Feb 2012 07:56:16 +0100 Subject: changing key as security feature in osmocom? In-Reply-To: References: Message-ID: <4F38B410.7090503@eversberg.eu> > ok, I hope its correct and conventional now. hi tim, looks good to me. regards, andreas From jakahudoklin at gmail.com Wed Feb 15 21:19:05 2012 From: jakahudoklin at gmail.com (Jaka Hudoklin) Date: Wed, 15 Feb 2012 15:19:05 -0600 Subject: Problem with decoding. Message-ID: Hello. I'm trying to figure out what am i doing wrong for days, and i can't. I'm doing GSM security research for my university. I sniffed A5/1 encrypted bursts of my mobile phone with known KC. The example of burst output is below(C-cyphertext, P-plaintext, F- decoded data): > C 2310735 > 111000010011011101110001010111110100001010101111110001110100011010011011101100101100010010011011010100101111100111 > P 2310735 > 100000000001110111010100000000000001000011011101000000001000000000010101110100000100000010000101010111010101000010 > C 2310736 > 101110101001101010010111111111101010111001111001001110011000011111011001010010010111110010010000111000111011100011 > P 2310736 > 101011111111010101010001100000101010111111010101000100001010111110111101110100010010100010111011111101010001001010 > C 2310737 > 100011010101111101001111011110111010100001010010100010010110000010111110001011010010100111101000011110010100100101 > P 2310737 > 000100010111010100010000101000010100011101010000000010100001000101110101010000000000100001000111010101000000001010 > C 2310738 > 100011100100110101110100001001001111110110110000001101100110001101100011011000011011111111011100101110100000101111 > P 2310738 > 010100001000101011101101010101010100001010111111110101110100000010101010101011010101010100001000101010101101110101 > F 1 22 9 6 32 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b > C 2310752 > 110011010101101010011000000101011010111000001111110111011101011010111101110101000101101001110001000000100000101011 > P 2310752 > 111000101001100101011000011010100001110010100101111101010011000111000111011100110001111110111100000111110100000101 > C 2310753 > 011010111101000101101001001111001001100001101010001011110111011000010101100001000100101010100110110100001000110111 > P 2310753 > 000011111011011101100101100000101011111000100110110001010110010011101111111011000000110010011110001011011000010010 > C 2310754 > 011011000011001100000110001110000011010100000101100000011111101100101000011001001010100001011100001011111011001011 > P 2310754 > 100000010010110101010001101110110100000110011101010111100010100000001001010101011001001001100010101101110100101010 > C 2310755 > 001001010111101010011010100110100011101001010101010010001011111101001000000111101101001011001111001001010001010011 > P 2310755 > 111001001001100011101001100100110100100000110010100110011101010000101010010010101011010001011000000001001100101111 > F 5 3 3 3 2d 6 1e 7 1e 92 f3 14 0 3b 97 88 2b 2b 2b 2b 2b 2b 2b As you can see frames are decoded correctly and they are correctly displayed in wireshark. If i put XOR-ed value betwene cyprtext and plaintext-> keystream to kraken, i don't get any usefull results only the ones that do not produce correct KC. i calculate frame count correctly, because i test it with data from http://lists.lists.reflextor.com/pipermail/a51/2010-July/000803.html. Kraken works correctly for me since i can get correct kc with keystream from http://lists.lists.reflextor.com/pipermail/a51/2010-July/000688.html. The ouput bursts in example above are written using following lines of code: for (i=0; i<57; i++) fprintf( app_state.fh, "%d", bt[i] ); for (i=59; i<116; i++) fprintf( app_state.fh, "%d", bt[i] ); where bt is generated using: osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); osmo_pbit2ubit_ext(bt, 59, bi->bits, 57, 57, 0); Can you help me identify why can't i correctly crack bursts? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakahudoklin at gmail.com Wed Feb 15 21:21:04 2012 From: jakahudoklin at gmail.com (Jaka Hudoklin) Date: Wed, 15 Feb 2012 15:21:04 -0600 Subject: Problem with decoding. In-Reply-To: References: Message-ID: Also KC for above data bursts is 986709C7CBA122FB. Thanks again! On Wed, Feb 15, 2012 at 3:19 PM, Jaka Hudoklin wrote: > Hello. > > I'm trying to figure out what am i doing wrong for days, and i can't. I'm > doing GSM security research for my university. > > I sniffed A5/1 encrypted bursts of my mobile phone with known KC. The > example of burst output is below(C-cyphertext, P-plaintext, F- decoded > data): > >> C 2310735 >> 111000010011011101110001010111110100001010101111110001110100011010011011101100101100010010011011010100101111100111 >> P 2310735 >> 100000000001110111010100000000000001000011011101000000001000000000010101110100000100000010000101010111010101000010 >> C 2310736 >> 101110101001101010010111111111101010111001111001001110011000011111011001010010010111110010010000111000111011100011 >> P 2310736 >> 101011111111010101010001100000101010111111010101000100001010111110111101110100010010100010111011111101010001001010 >> C 2310737 >> 100011010101111101001111011110111010100001010010100010010110000010111110001011010010100111101000011110010100100101 >> P 2310737 >> 000100010111010100010000101000010100011101010000000010100001000101110101010000000000100001000111010101000000001010 >> C 2310738 >> 100011100100110101110100001001001111110110110000001101100110001101100011011000011011111111011100101110100000101111 >> P 2310738 >> 010100001000101011101101010101010100001010111111110101110100000010101010101011010101010100001000101010101101110101 >> F 1 22 9 6 32 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b >> C 2310752 >> 110011010101101010011000000101011010111000001111110111011101011010111101110101000101101001110001000000100000101011 >> P 2310752 >> 111000101001100101011000011010100001110010100101111101010011000111000111011100110001111110111100000111110100000101 >> C 2310753 >> 011010111101000101101001001111001001100001101010001011110111011000010101100001000100101010100110110100001000110111 >> P 2310753 >> 000011111011011101100101100000101011111000100110110001010110010011101111111011000000110010011110001011011000010010 >> C 2310754 >> 011011000011001100000110001110000011010100000101100000011111101100101000011001001010100001011100001011111011001011 >> P 2310754 >> 100000010010110101010001101110110100000110011101010111100010100000001001010101011001001001100010101101110100101010 >> C 2310755 >> 001001010111101010011010100110100011101001010101010010001011111101001000000111101101001011001111001001010001010011 >> P 2310755 >> 111001001001100011101001100100110100100000110010100110011101010000101010010010101011010001011000000001001100101111 >> F 5 3 3 3 2d 6 1e 7 1e 92 f3 14 0 3b 97 88 2b 2b 2b 2b 2b 2b 2b > > > As you can see frames are decoded correctly and they are correctly > displayed in wireshark. > > If i put XOR-ed value betwene cyprtext and plaintext-> keystream to > kraken, i don't get any usefull results only the ones that do not produce > correct KC. i calculate frame count correctly, because i test it with data > from http://lists.lists.reflextor.com/pipermail/a51/2010-July/000803.html. > Kraken works correctly for me since i can get correct kc with keystream > from http://lists.lists.reflextor.com/pipermail/a51/2010-July/000688.html > . > > The ouput bursts in example above are written using following lines of > code: > for (i=0; i<57; i++) > fprintf( app_state.fh, "%d", bt[i] ); > for (i=59; i<116; i++) > fprintf( app_state.fh, "%d", bt[i] ); > where bt is generated using: > osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); > osmo_pbit2ubit_ext(bt, 59, bi->bits, 57, 57, 0); > > Can you help me identify why can't i correctly crack bursts? > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b8.adel at gmail.com Fri Feb 17 18:38:40 2012 From: b8.adel at gmail.com (adel) Date: Fri, 17 Feb 2012 10:38:40 -0800 (PST) Subject: Problem with decoding. In-Reply-To: References: Message-ID: <1329503920066-3754572.post@n3.nabble.com> do you use usrp or you use osmocombb osmo-bts ? if you know how to use osmocombb bts Please help me -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Problem-with-decoding-tp3748456p3754572.html Sent from the baseband-devel mailing list archive at Nabble.com. From 246tnt at gmail.com Fri Feb 17 19:18:35 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 17 Feb 2012 20:18:35 +0100 Subject: Problem with decoding. In-Reply-To: <1329503920066-3754572.post@n3.nabble.com> References: <1329503920066-3754572.post@n3.nabble.com> Message-ID: > do you use usrp or you use osmocombb osmo-bts ? > if you know how to use osmocombb bts Please help me There is no such thing ... you can't possibly use something that doesn't exist. Sylvain From osmocom at ehlers.info Sun Feb 19 17:30:57 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 19 Feb 2012 18:30:57 +0100 (CET) Subject: Reliablility problem in current git? Message-ID: Hi, I have a git clone from 23.01.2012 and a current git clone. When I compile both and use the mobile appliation, I have a strange problem in the current code. Very often I can't send USSD codes (and maybe also can't communicate in other ways; USSD is the costless way to check whether I am connected or not). Ok, this is what I do: I send "service 1 *#21#", wait the answer and the string "% On Network, normal service: Germany, O2". Then send it again and so on. With the old code, I reliable get the answer e.g. "% Status: deactivated". With the new code, I very often (sometime already when trying first time) get nothing back and after some seconds only "% Service connection terminated.". Can someone confirm this behavior? Thanks Tim From osmocom at ehlers.info Sun Feb 19 22:19:36 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 19 Feb 2012 23:19:36 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: On Sun, 19 Feb 2012, Tim Ehlers wrote: Hi, (just to tell everyone) > When I compile both and use the mobile appliation, I have a strange problem I can now say its not the mobile application (layer23). Its the new layer1. When using the current mobile application with the old layer1.compalram.bin, its working. Cheers Tim From 246tnt at gmail.com Sun Feb 19 22:35:09 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 19 Feb 2012 23:35:09 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: > I can now say its not the mobile application (layer23). Its the new layer1. > When using the current mobile application with the old layer1.compalram.bin, > its working. Define "old" .... Are you using the sylvain/testing branch in both case ? Cheers, Sylvain From osmocom at ehlers.info Sun Feb 19 22:41:02 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 19 Feb 2012 23:41:02 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: On Sun, 19 Feb 2012, Sylvain Munaut wrote: Hi Sylvain, >> I can now say its not the mobile application (layer23). Its the new >> layer1. When using the current mobile application with the old >> layer1.compalram.bin, its working. > > Define "old" .... > > Are you using the sylvain/testing branch in both case ? no, shall I? :) I just checked out the main branch: git clone git://git.osmocom.org/osmocom-bb.git The "old" one is from 23.01. and it seems that layer1 is somehow new since then. It now shows different string in the phone display and you can't stop it with just shortly pressing power, but pressing for some seconds. Cheers Tim From 246tnt at gmail.com Sun Feb 19 22:43:58 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 19 Feb 2012 23:43:58 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: Hi, >> Are you using the sylvain/testing branch in both case ? > > > no, shall I? :) Yes :) there is an ugly hack to workaround a known issue ... > The "old" one is from 23.01. and it seems that layer1 is somehow new since > then. It now shows different string in the phone display and you can't stop > it with just shortly pressing power, but pressing for some seconds. Do you have commit id ? Cheers, Sylvain From peter at stuge.se Sun Feb 19 22:49:01 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 23:49:01 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: <20120219224901.6433.qmail@stuge.se> Sylvain Munaut wrote: > > The "old" one is from 23.01. and it seems that layer1 is somehow new since > > then. It now shows different string in the phone display and you can't stop > > it with just shortly pressing power, but pressing for some seconds. > > Do you have commit id ? Run e.g. git show and it's the first line. //Peter From osmocom at ehlers.info Sun Feb 19 23:02:18 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 20 Feb 2012 00:02:18 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: <20120219224901.6433.qmail@stuge.se> References: <20120219224901.6433.qmail@stuge.se> Message-ID: On Sun, 19 Feb 2012, Peter Stuge wrote: >>> The "old" one is from 23.01. and it seems that layer1 is somehow new since >>> then. It now shows different string in the phone display and you can't stop >>> it with just shortly pressing power, but pressing for some seconds. >> >> Do you have commit id ? > > Run e.g. git show and it's the first line. ahh, you mean the commit id from working tree? It should be 2c02043f490704805c17f787394403de93d0b9c6. But, as I wrote, I don't know since when (after this commit) the problem exists. Cheers Tim From peter at stuge.se Sun Feb 19 23:16:22 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 00:16:22 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: <20120219224901.6433.qmail@stuge.se> Message-ID: <20120219231622.8370.qmail@stuge.se> Tim Ehlers wrote: >>> Do you have commit id ? >> >> Run e.g. git show and it's the first line. > > ahh, you mean the commit id from working tree? It should be > 2c02043f490704805c17f787394403de93d0b9c6. But, as I wrote, I don't > know since when (after this commit) the problem exists. In the newer clone you can also check the commit id, then git bisect can be used to find which commit introduced the problem. http://book.git-scm.com/5_finding_issues_-_git_bisect.html http://progit.org/book/ch6-5.html //Peter From osmocom at ehlers.info Sun Feb 19 22:53:16 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 19 Feb 2012 23:53:16 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: On Sun, 19 Feb 2012, Sylvain Munaut wrote: >>> Are you using the sylvain/testing branch in both case ? >> >> no, shall I? :) > > Yes :) > > there is an ugly hack to workaround a known issue ... ok, I try that tomorrow. >> The "old" one is from 23.01. and it seems that layer1 is somehow new >> since then. It now shows different string in the phone display and you >> can't stop it with just shortly pressing power, but pressing for some >> seconds. > > Do you have commit id ? no, thats the problem. I checked out at 23.01. and the current git. I know, the tree from 23.01. has a working layer1 (what I wrote in first mail). I would tip, that it has to do with the 'git-subtree' update from Harald, where he wrote: > Nonetheless, if you experience strange new problems, the libosmocore > update might be a possible cause. But its just a guess. Tim From jean-pierre.szikora at uclouvain.be Mon Feb 20 11:13:21 2012 From: jean-pierre.szikora at uclouvain.be (Jean-Pierre Szikora) Date: Mon, 20 Feb 2012 12:13:21 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: Message-ID: <4F422AD1.9090301@uclouvain.be> Le 19/02/12 18:30, Tim Ehlers a ?crit : > Hi, > > I have a git clone from 23.01.2012 and a current git clone. > > When I compile both and use the mobile appliation, I have a strange > problem in the current code. Very often I can't send USSD codes (and > maybe also can't communicate in other ways; USSD is the costless way > to check whether I am connected or not). > > Ok, this is what I do: I send "service 1 *#21#", wait the answer and > the string "% On Network, normal service: Germany, O2". Then send it > again and so on. > > With the old code, I reliable get the answer e.g. "% Status: > deactivated". With the new code, I very often (sometime already when > trying first time) get nothing back and after some seconds only "% > Service connection terminated.". > > Can someone confirm this behavior? Hi, I have the same problem (testing with a C123). When this problem occurs, I have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: 24". With git bisect, I localize the first commit showing this issue as 7cc4a4b ( Improvement of neighbour cell power measurement task). Hope this help, Cheers, Jean-Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Feb 20 12:14:10 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 20 Feb 2012 13:14:10 +0100 Subject: Reliablility problem in current git? In-Reply-To: <4F422AD1.9090301@uclouvain.be> References: <4F422AD1.9090301@uclouvain.be> Message-ID: Hi, > I have the same problem (testing with a C123). When this problem occurs, I > have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: > 24". With git bisect, I localize the first commit showing this issue as > 7cc4a4b ( Improvement of neighbour cell power measurement task). Oh yes, that commit looks like a very bad idea ... neigh measurement should always be on TN 0 ... Can you try to undo that chunk : diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c index 07b7209..1630600 100644 --- a/src/target/firmware/layer1/prim_pm.c +++ b/src/target/firmware/layer1/prim_pm.c @@ -175,7 +175,8 @@ static int l1s_neigh_pm_cmd(uint8_t num_meas, * num_meas > 1 */ /* do measurement dummy, in case l1s.neigh_pm.n == 0 */ l1s_rx_win_ctrl((l1s.neigh_pm.n) ? - l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, L1_RXWIN_PW, 0); + l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, + L1_RXWIN_PW, l1s.neigh_pm.tn[l1s.neigh_pm.pos]); /* restore last gain */ rffe_set_gain(last_gain); And check if it improves things. Cheers, Sylvain From jean-pierre.szikora at uclouvain.be Mon Feb 20 12:49:56 2012 From: jean-pierre.szikora at uclouvain.be (Jean-Pierre Szikora) Date: Mon, 20 Feb 2012 13:49:56 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> Message-ID: <4F424174.6060608@uclouvain.be> Le 20/02/12 13:14, Sylvain Munaut a ?crit : > Hi, > >> I have the same problem (testing with a C123). When this problem occurs, I >> have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: >> 24". With git bisect, I localize the first commit showing this issue as >> 7cc4a4b ( Improvement of neighbour cell power measurement task). > Oh yes, that commit looks like a very bad idea ... neigh measurement > should always be on TN 0 ... > > Can you try to undo that chunk : > Hi Sylvain, I applied this patch: diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile index 3af2f67..0e0ec8b 100644 --- a/src/target/firmware/Makefile +++ b/src/target/firmware/Makefile @@ -95,7 +95,7 @@ ANY_APP_LIBS+=calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm -include Makefile.inc # Uncomment this line if you want to enable Tx (Transmit) Support. -#CFLAGS += -DCONFIG_TX_ENABLE +CFLAGS += -DCONFIG_TX_ENABLE # Uncomment this line if you want to write to flash. #CFLAGS += -DCONFIG_FLASH_WRITE diff --git a/src/target/firmware/board/compal/highram.lds b/src/target/firmware/board/compal/highram.lds index 498a2fa..41786d3 100644 --- a/src/target/firmware/board/compal/highram.lds +++ b/src/target/firmware/board/compal/highram.lds @@ -16,9 +16,9 @@ MEMORY /* lowram: could be anything, we place exception vectors here */ XRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000 /* highram binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00014000 + LRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00015000 /* highram binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x00834000, LENGTH = 0x0000c000 + IRAM (rw) : ORIGIN = 0x00835000, LENGTH = 0x0000c000 } SECTIONS { diff --git a/src/target/firmware/board/compal/ram.lds b/src/target/firmware/board/compal/ram.lds index 9503ede..acc72ca 100644 --- a/src/target/firmware/board/compal/ram.lds +++ b/src/target/firmware/board/compal/ram.lds @@ -11,9 +11,9 @@ ENTRY(_start) MEMORY { /* compal-loaded binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00014000 + LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00015000 /* compal-loaded binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x00814000, LENGTH = 0x0000c000 + IRAM (rw) : ORIGIN = 0x00815000, LENGTH = 0x0000c000 } SECTIONS { diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c index 1630600..84b5161 100644 --- a/src/target/firmware/layer1/prim_pm.c +++ b/src/target/firmware/layer1/prim_pm.c @@ -175,8 +175,7 @@ static int l1s_neigh_pm_cmd(uint8_t num_meas, * num_meas > 1 */ /* do measurement dummy, in case l1s.neigh_pm.n == 0 */ l1s_rx_win_ctrl((l1s.neigh_pm.n) ? - l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, - L1_RXWIN_PW, l1s.neigh_pm.tn[l1s.neigh_pm.pos]); + l1s.neigh_pm.band_arfcn[l1s.neigh_pm.pos] : 0, L1_RXWIN_PW, 0); /* restore last gain */ rffe_set_gain(last_gain); The issue is not solved with this. I still have plenty DSP Error Status in the Layer1 output (in attachment). And I can not request any service (*#21# for exemple). Cheers, Jean-Pierre -------------- next part -------------- A non-text attachment was scrubbed... Name: osmocom_layer1.txt.zip Type: application/zip Size: 1708 bytes Desc: not available URL: From osmocom at ehlers.info Mon Feb 20 18:44:21 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 20 Feb 2012 19:44:21 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: <4F422AD1.9090301@uclouvain.be> References: <4F422AD1.9090301@uclouvain.be> Message-ID: On Mon, 20 Feb 2012, Jean-Pierre Szikora wrote: Hi, > I have the same problem (testing with a C123). When this problem occurs, I > have also a lot of "DSP Error Status: 8" and afterwards "DSP Error Status: > 24". With git bisect, I localize the first commit showing this issue as > 7cc4a4b ( Improvement of neighbour cell power measurement task). > > Hope this help, yes, very much. I had problems with bisect. It told me, that there are more than 550 revisions to check and most of them where older than the bad one... So you findings helped me to track the problem down to this: --- mframe_sched.c 2012-02-20 19:37:42.000000000 +0100 +++ mframe_sched.c~ 2012-02-20 19:33:24.000000000 +0100 @@ -200,7 +200,11 @@ /* Measurement for MF 51 */ static const struct mframe_sched_item mf_neigh_pm51[] = { - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 50 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 10 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 20 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 30 }, + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 40 }, { .sched_set = NULL } }; in the changeset 7cc4a4b324bcf65b5d383faf2b3e727953c8df81. Not that I would understand what this means... :) Harald can you fix your changes with that info? Thanks Tim From osmocom at ehlers.info Mon Feb 20 18:54:54 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 20 Feb 2012 19:54:54 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> Message-ID: On Mon, 20 Feb 2012, Tim Ehlers wrote: > Harald can you fix your changes with that info? ahh, I just saw git-author is Andreas. So Andreas, can you fix your changes with that info? Cheers Tim From 246tnt at gmail.com Mon Feb 20 19:17:59 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 20 Feb 2012 20:17:59 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> Message-ID: So reverting that commit fixes your issues ? Cheers, Sylvain From osmocom at ehlers.info Mon Feb 20 19:23:08 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 20 Feb 2012 20:23:08 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> Message-ID: On Mon, 20 Feb 2012, Sylvain Munaut wrote: > So reverting that commit fixes your issues ? yes, it seems so. I mean I don't have longterm tests now, but cloning current git, reverting the part from the commit I wrote, I made 10 "service 2 *#21#" in a row without problems. So I assume, that this fixes the issue. Cheers Tim From jean-pierre.szikora at uclouvain.be Tue Feb 21 09:58:25 2012 From: jean-pierre.szikora at uclouvain.be (Jean-Pierre Szikora) Date: Tue, 21 Feb 2012 10:58:25 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> Message-ID: <4F436AC1.1000603@uclouvain.be> Le 20/02/12 20:23, Tim Ehlers a ?crit : > On Mon, 20 Feb 2012, Sylvain Munaut wrote: > >> So reverting that commit fixes your issues ? > > yes, it seems so. I mean I don't have longterm tests now, but cloning > current git, reverting the part from the commit I wrote, I made 10 > "service 2 *#21#" in a row without problems. > > So I assume, that this fixes the issue. I tested it also. Service and SMS sending is working, but regular call is still broken (still plenty DSP Error Status in Layer1 output). Cheers, Jean-Pierre From osmocom at ehlers.info Thu Feb 23 08:10:40 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Thu, 23 Feb 2012 09:10:40 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: <4F436AC1.1000603@uclouvain.be> References: <4F422AD1.9090301@uclouvain.be> <4F436AC1.1000603@uclouvain.be> Message-ID: On Tue, 21 Feb 2012, Jean-Pierre Szikora wrote: Hi, >>> So reverting that commit fixes your issues ? >> >> yes, it seems so. I mean I don't have longterm tests now, but cloning >> current git, reverting the part from the commit I wrote, I made 10 >> "service 2 *#21#" in a row without problems. >> >> So I assume, that this fixes the issue. > I tested it also. Service and SMS sending is working, but regular call > is still broken (still plenty DSP Error Status in Layer1 output). yesterday I made a quick call test and you are right, calling is still broken. I could call a number, it is ringing and after pickup the call is released (that happend in my quick test yesterday; I didn't have the time to test more/again). Could someone check this too? Is there someone, not having problems in the current git? Cheers, Tim From 246tnt at gmail.com Thu Feb 23 08:30:25 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 23 Feb 2012 09:30:25 +0100 Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> <4F436AC1.1000603@uclouvain.be> Message-ID: > yesterday I made a quick call test and you are right, calling is still > broken. I could call a number, it is ringing and after pickup the call is > released (that happend in my quick test yesterday; I didn't have the time to > test more/again). Did you use the sylvain/testing branch as a base this time ? Cheers, Sylvain From osmocom at ehlers.info Thu Feb 23 08:47:38 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Thu, 23 Feb 2012 09:47:38 +0100 (CET) Subject: Reliablility problem in current git? In-Reply-To: References: <4F422AD1.9090301@uclouvain.be> <4F436AC1.1000603@uclouvain.be> Message-ID: On Thu, 23 Feb 2012, Sylvain Munaut wrote: Hi Sylvain, >> yesterday I made a quick call test and you are right, calling is still >> broken. I could call a number, it is ringing and after pickup the call is >> released (that happend in my quick test yesterday; I didn't have the time to >> test more/again). > > Did you use the sylvain/testing branch as a base this time ? as I can see you mean this patch, right?: http://bb.osmocom.org/trac/changeset/fe3c81ecc454266b0ccd14a3c0f502db1413f041/ It's the only difference between master and sylvain/testing. This patch I tried. It doesn't change a thing in this issue. And the call yesterday was your testing branch plus: --- mframe_sched.c 2012-02-20 19:37:42.000000000 +0100 +++ mframe_sched.c~ 2012-02-20 19:33:24.000000000 +0100 @@ -200,7 +200,11 @@ /* Measurement for MF 51 */ static const struct mframe_sched_item mf_neigh_pm51[] = { + { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 50 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 0 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 10 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 20 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 30 }, - { .sched_set = NEIGH_PM , .modulo = 51, .frame_nr = 40 }, { .sched_set = NULL } }; Cheers Tim From alhakeem at gmail.com Mon Feb 20 15:26:55 2012 From: alhakeem at gmail.com (Abdul Hakeem) Date: Mon, 20 Feb 2012 15:26:55 -0000 Subject: USSD Commands Message-ID: Hello, Does anyone have a comprehensive list of USSD commands (either at the MS and server sides ), or a link to such a resource ? Regards, Abdul Hakeem From to_beat at hotmail.com Mon Feb 20 17:59:36 2012 From: to_beat at hotmail.com (To Beat) Date: Mon, 20 Feb 2012 18:59:36 +0100 Subject: Network registration fails Message-ID: Hi I've a problem with the mobile application since ~1 month. Registering in the network always fails and I don't have any idea why. It used to work in the past, but currently it is not working. Independently from the osmocom version i use (even the version from december 2011 which had worked once now always fail). I am using a C123 with an ftdi cable and the testing branch from sylvain. I tried sim cards for Vodafone/O2/Eplus. The related outputs/logs are the following: Output on telnet interface: OsmocomBB# % (MS 1) % Searching network... % (MS 1) % Trying to registering with network... layer 1 output: http://pastebin.com/c0AhJ3gt mobile app output: http://pastebin.com/vP0YPfpT Any suggestions are appreciated! greetings Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmocom at ehlers.info Mon Feb 20 18:46:00 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 20 Feb 2012 19:46:00 +0100 (CET) Subject: Network registration fails In-Reply-To: References: Message-ID: On Mon, 20 Feb 2012, To Beat wrote: Hi, > I've a problem with the mobile application since ~1 month. Registering > in the network always fails and I don't have any idea why. It used to > work in the past, but currently it is not working. Independently from > the osmocom version i use (even the version from december 2011 which had > worked once now always fail). I would think its the same we discuss in "Reliablility problem in current git?" Cheers Tim From osmocom at ehlers.info Mon Feb 20 20:03:29 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Mon, 20 Feb 2012 21:03:29 +0100 (CET) Subject: [PATCH] bind VTY to other interfaces than localhost Message-ID: Hi, in some usecases, for people knowing what they are doing, it maybe an advantage to control osmocombb over the network. Since the VTY is already network capable, it just needs to bind to an alternative network interface than localhost. Here is a patch for layer23 (mobile), having an option "-u" (because -v is the port). Passing "-u 0.0.0.0" would bind to any interface. If you think it is useful, please commit it in the git. Cheers Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: telnet.patch Type: text/x-patch Size: 7416 bytes Desc: URL: From 246tnt at gmail.com Mon Feb 20 20:13:14 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 20 Feb 2012 21:13:14 +0100 Subject: [PATCH] bind VTY to other interfaces than localhost In-Reply-To: References: Message-ID: > If you think it is useful, please commit it in the git. It is. Unfortunately, it's changing libosmocore, so that makes it a whole lot more complex because you can't change the "shared" directory directly, we need to make the change to libosmocore then import the new libosmocore into the osmocom-bb git. And we have to maintain compatibility in libosmocore as much as possible if we don't want to break everything that calls telnet_init, so I would recommend introducing a new telnet_init_ex ? that takes the added parameter and keep telnet_init as compatibility. Harald / Holger ? Do you see better ways to handle this sort of case ? Cheers, Sylvain From peter at stuge.se Mon Feb 20 20:27:18 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 21:27:18 +0100 Subject: [PATCH] bind VTY to other interfaces than localhost In-Reply-To: References: Message-ID: <20120220202718.8028.qmail@stuge.se> Sylvain Munaut wrote: > Unfortunately, it's changing libosmocore, so that makes it a whole lot > more complex because you can't change the "shared" directory directly, > we need to make the change to libosmocore then import the new > libosmocore into the osmocom-bb git. Yes, good point. > And we have to maintain compatibility in libosmocore as much as > possible if we don't want to break everything that calls telnet_init, > so I would recommend introducing a new telnet_init_ex ? that takes the > added parameter and keep telnet_init as compatibility. Are there many uses of telnet_init which can not be fixed very quickly? > Harald / Holger ? Do you see better ways to handle this sort of case ? For a "locked" API there's no other way.. Either get the API right the first time, or pass an extensible set of options. The former is nice and neat, the latter is a little more complicated. I think adding a new function is fine, but maybe choose a more descript name than just the _ex suffix? :) //Peter From laforge at gnumonks.org Tue Feb 21 15:50:49 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Feb 2012 16:50:49 +0100 Subject: [PATCH] bind VTY to other interfaces than localhost In-Reply-To: <20120220202718.8028.qmail@stuge.se> References: <20120220202718.8028.qmail@stuge.se> Message-ID: <20120221155049.GA29148@prithivi.gnumonks.org> Hi all, On Mon, Feb 20, 2012 at 09:27:18PM +0100, Peter Stuge wrote: > > And we have to maintain compatibility in libosmocore as much as > > possible if we don't want to break everything that calls telnet_init, > > so I would recommend introducing a new telnet_init_ex ? that takes the > > added parameter and keep telnet_init as compatibility. > > Are there many uses of telnet_init which can not be fixed very quickly? the problem with fre software is that you never know ;) At least in openbsc/cellmgr-ng/osmo-sgsn/osmo-nitb/osmo-bsc_mgcp, etc. they all use the existing function. Also, we really want to avoid the situation where older versions of openbsc suddenly don't work with a later version of libosmocore. I agree that non-local-binding should have been implemented a long time ago. Usinga 'char *' for the ip/hostname is also the right thing to do. However, please don't introduce ipv4 assumptions unless required, so using proper getnameinfo would make sense. It would also be a good time to start using the general socket helper code of libosmocore (osmo_sock_init/osmo_sock_init_ofd) to remove code duplication. A patch along those lines would be appreciated. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Mon Feb 20 20:24:24 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 21:24:24 +0100 Subject: [PATCH] bind VTY to other interfaces than localhost In-Reply-To: References: Message-ID: <20120220202424.7777.qmail@stuge.se> Hi Tim, Tim Ehlers wrote: > Here is a patch for layer23 (mobile), having an option "-u" (because > -v is the port). Passing "-u 0.0.0.0" would bind to any interface. I think this is a fun idea, but I have some small comments. > If you think it is useful, please commit it in the git. Please consider the comments, and then re-send a patch created locally by you using git. It's easy: One-time setup: git config --global user.name 'Tim Ehlers' git config --global user.email your at email.address To create a commit: git diff # to review your changes and decide that you want them git commit -a # to create a new commit in your local dir with the changes Please write a descriptive and nicely formatted commit message. Your commit message will be visible in many places, so it's a good idea to make it look really good. It's easy. Here's an example: -->8-- First line a short description of the logical change, absmax 72 chars Leave the second line blank, and then, if it makes sense for the commit, (I don't think neccessary for this one) you can continue writing a more detailed explanation on lines three and forward. Always keep line lengths limited. Best is to stay near 70, absmax 76. Finally, you can end the commit message with a signoff, this practise has agreed-upon legal meaning within the Linux kernel, but isn't yet used in the same way within osmocom-bb. It's not wrong to do it anyway. Signed-off-by: Your Name --8<-- To generate a patch file for the last 1 commit: git format-patch -1 Or to have git send the patch directly to the mailing list: git config sendemail.to baseband-devel at lists.osmocom.org # one-time setup git send-email -1 Or to transmit a copy of your local commits to elsewhere: # register e.g. on github.com git push I really like the git send-email feature. It's great when contributing sporadically, because you don't neccessarily have to remember the email address once it has been configured in the git repo! :) All git commands can be run with --help to learn about their further capabilities. //Peter From GNUtoo at no-log.org Mon Feb 20 20:07:38 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Mon, 20 Feb 2012 21:07:38 +0100 Subject: nuxttx-bb issues Message-ID: <201202202107.38861.GNUtoo@no-log.org> hi, Me and Alan Carvalho de Assis tried nuttx-bb on the calypso and we failed to get any serial or sercomm output. The setup: ------------ 1) clone the following repository(or add as remote and checkout the correct branch): git://git.osmocom.org/osmocom-bb git://gitorious.org/gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb- gta02.git osmocom-bb and nuttx-bb-gta02 must be in the same directory. nuttx-bb-gta02 has 2 small patches made by me. One is for fixing compilation. And the other one is the result of a diff between compal_e99's init.c and the gta02's init.c 2) setup the toolchain: we didn't use gnuarm toolchain because it gave that when compiling nuttx-bb: arm-elf-ld: ERROR: /home/gnutoo/temp/osmo/nuttx-bb-gta02/nuttx/../../osmocom- bb/src/target/firmware/comm/libcomm.a(sercomm.o) uses hardware FP, whereas /home/gnutoo/temp/osmo/nuttx-bb-gta02/nuttx/nuttx uses software FP So we tried the arm-2010.09 codesourcey we put it in the path. 3) compile osmocom-bb: cd osmocom-bb/src make clean make cd ../../ 3) compile nuttx-bb: cd nuttx-bb-gta02/nuttx cd tools ./configure.sh compal_e99/nsh cd ../ make CROSSDEV="arm-none-eabi-" clean make CROSSDEV="arm-none-eabi-" that gives a file named nuttx.bin Then I tried it to load on my om-gta02: scp nuttx.bin root at 192.168.7.2: ssh root at 192.168.7.2 root at om-gta02:~# /etc/init.d/dbus-1 stop Stopping system message bus: root at om-gta02:~# /etc/init.d/xserver-nodm stop Stopping XServer root at om-gta02:~# osmocon -i 13 -m romload -p /dev/ttySAC0 nuttx.bin and on another console: ssh root at 192.168.7.2 root at om-gta02:~# echo 1 > /sys/bus/platform/devices/gta02-pm-gsm.0/download root at om-gta02:~# echo 0 >/sys/bus/platform/devices/gta02-pm-gsm.0/power_on root at om-gta02:~# echo 1 >/sys/bus/platform/devices/gta02-pm-gsm.0/power_on which results in the following on the first console: [...] Finished, sent 63 blocks in total Received block ack from phone Sending checksum: 0xf6 Checksum on phone side matches, let's branch to your code Branching to 0x00820000 Received branch ack, your code is running now! but nothing on sercomm. And nothing on IRDA serial port either.... and IRDA serial cable works too: if I do that again: root at om-gta02:~# echo 0 >/sys/bus/platform/devices/gta02-pm-gsm.0/power_on root at om-gta02:~# echo 1 >/sys/bus/platform/devices/gta02-pm-gsm.0/power_on I get the default modem software messages on the serial port... Previously I tried to print on the IRDA serial port with: cons_puts("HELLO WORLD\n\n"); in apps/examples/hello/main.c and of course enabling the hello world application in the apps config. Nothing was printed either.... here's the app config: CONFIGURED_APPS += examples/hello in apps/.config And here's the diff for the application: diff --git a/apps/examples/hello/main.c b/apps/examples/hello/main.c index 308603f..db55ac3 100644 --- a/apps/examples/hello/main.c +++ b/apps/examples/hello/main.c @@ -58,7 +58,10 @@ int user_start(int argc, char *argv[]) { - printf("Hello, World!!\n"); - return 0; + while (1){ + cons_puts("HELLO WORLD\n"); + printf("Hello, World!!\n"); + } + return 0; } Alan Carvalho de Assis tried on features phones and not on the gta02 with the same result... Denis. From laforge at gnumonks.org Tue Feb 21 15:52:19 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Feb 2012 16:52:19 +0100 Subject: nuxttx-bb issues In-Reply-To: <201202202107.38861.GNUtoo@no-log.org> References: <201202202107.38861.GNUtoo@no-log.org> Message-ID: <20120221155219.GB29148@prithivi.gnumonks.org> hi Denis, On Mon, Feb 20, 2012 at 09:07:38PM +0100, Denis 'GNUtoo' Carikli wrote: > Me and Alan Carvalho de Assis tried nuttx-bb on the calypso and we failed to > get any serial or sercomm output. thanks for looking into it. > git://git.osmocom.org/osmocom-bb > git://gitorious.org/gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb- > gta02.git > osmocom-bb and nuttx-bb-gta02 must be in the same directory. > nuttx-bb-gta02 has 2 small patches made by me. Can you please send them to this list (e.g. using git format-patch or git send-email?) This makes reviewing them much easier. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocom at ehlers.info Tue Feb 21 12:22:20 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Tue, 21 Feb 2012 13:22:20 +0100 Subject: [PATCH] Added option for mobile-app to bind to other interfaces than localhost. Signed-off-by: Tim Ehlers Message-ID: <1329826940-21171-1-git-send-email-osmocom@ehlers.info> --- .../layer23/include/osmocom/bb/common/l23_app.h | 1 + .../layer23/include/osmocom/bb/mobile/app_mobile.h | 2 +- src/host/layer23/src/common/main.c | 11 ++++- src/host/layer23/src/mobile/app_mobile.c | 4 +- src/host/layer23/src/mobile/main.c | 13 ++++- .../include/osmocom/vty/telnet_interface.h | 1 + src/shared/libosmocore/src/vty/telnet_interface.c | 45 ++++++++++++++++++++ 7 files changed, 70 insertions(+), 7 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/l23_app.h b/src/host/layer23/include/osmocom/bb/common/l23_app.h index e4c5d55..0b9994c 100644 --- a/src/host/layer23/include/osmocom/bb/common/l23_app.h +++ b/src/host/layer23/include/osmocom/bb/common/l23_app.h @@ -10,6 +10,7 @@ enum { L23_OPT_TAP = 4, L23_OPT_VTY = 8, L23_OPT_DBG = 16, + L23_OPT_VTYIP = 32, }; /* initialization, called once when starting the app, before entering diff --git a/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h b/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h index 4010a68..351dec3 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h +++ b/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h @@ -4,7 +4,7 @@ char *config_dir; int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), - const char *config_file, uint16_t vty_port); + const char *config_file, const char *vty_ip, uint16_t vty_port); int l23_app_exit(void); int l23_app_work(int *quit); int mobile_delete(struct osmocom_ms *ms, int force); diff --git a/src/host/layer23/src/common/main.c b/src/host/layer23/src/common/main.c index eb47b26..59cee03 100644 --- a/src/host/layer23/src/common/main.c +++ b/src/host/layer23/src/common/main.c @@ -56,6 +56,7 @@ static char *sap_socket_path = "/tmp/osmocom_sap"; struct llist_head ms_list; static struct osmocom_ms *ms = NULL; static char *gsmtap_ip = NULL; +static char *vty_ip = "127.0.0.1"; unsigned short vty_port = 4247; int (*l23_app_work) (struct osmocom_ms *ms) = NULL; @@ -106,6 +107,10 @@ static void print_help() if (options & L23_OPT_DBG) printf(" -d --debug Change debug flags.\n"); + if (options & L23_OPT_VTYIP) + printf(" -u --vty-ip The VTY IP to bind telnet to. " + "(default %s)\n", vty_ip); + if (app && app->cfg_print_help) app->cfg_print_help(); } @@ -122,13 +127,14 @@ static void build_config(char **opt, struct option **option) {"sap", 1, 0, 'S'}, {"arfcn", 1, 0, 'a'}, {"gsmtap-ip", 1, 0, 'i'}, + {"vty-ip", 1, 0, 'u'}, {"vty-port", 1, 0, 'v'}, {"debug", 1, 0, 'd'}, }; app = l23_app_info(); - *opt = talloc_asprintf(l23_ctx, "hs:S:a:i:v:d:%s", + *opt = talloc_asprintf(l23_ctx, "hs:S:a:i:v:d:u:%s", app && app->getopt_string ? app->getopt_string : ""); len = ARRAY_SIZE(long_options); @@ -174,6 +180,9 @@ static void handle_options(int argc, char **argv) case 'i': gsmtap_ip = optarg; break; + case 'u': + vty_ip = optarg; + break; case 'v': vty_port = atoi(optarg); break; diff --git a/src/host/layer23/src/mobile/app_mobile.c b/src/host/layer23/src/mobile/app_mobile.c index da388b2..d911ab3 100644 --- a/src/host/layer23/src/mobile/app_mobile.c +++ b/src/host/layer23/src/mobile/app_mobile.c @@ -352,7 +352,7 @@ static struct vty_app_info vty_info = { /* global init */ int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), - const char *config_file, uint16_t vty_port) + const char *config_file, const char *vty_ip, uint16_t vty_port) { struct telnet_connection dummy_conn; int rc = 0; @@ -376,7 +376,7 @@ int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), } } vty_reading = 0; - telnet_init(l23_ctx, NULL, vty_port); + telnet_init_dynif(l23_ctx, NULL, vty_ip, vty_port); if (rc < 0) return rc; printf("VTY available on port %u.\n", vty_port); diff --git a/src/host/layer23/src/mobile/main.c b/src/host/layer23/src/mobile/main.c index 89c9b94..312bcd6 100644 --- a/src/host/layer23/src/mobile/main.c +++ b/src/host/layer23/src/mobile/main.c @@ -52,6 +52,7 @@ void *l23_ctx = NULL; struct llist_head ms_list; static char *gsmtap_ip = 0; struct gsmtap_inst *gsmtap_inst = NULL; +static char *vty_ip = "127.0.0.1"; unsigned short vty_port = 4247; int debug_set = 0; char *config_dir = NULL; @@ -88,6 +89,8 @@ static void print_help() printf(" Some help...\n"); printf(" -h --help this text\n"); printf(" -i --gsmtap-ip The destination IP used for GSMTAP.\n"); + printf(" -u --vty-ip The VTY IP to telnet to. " + "(default %s)\n", vty_ip); printf(" -v --vty-port The VTY port number to telnet to. " "(default %u)\n", vty_port); printf(" -d --debug Change debug flags. default: %s\n", @@ -104,6 +107,7 @@ static void handle_options(int argc, char **argv) static struct option long_options[] = { {"help", 0, 0, 'h'}, {"gsmtap-ip", 1, 0, 'i'}, + {"vty-ip", 1, 0, 'u'}, {"vty-port", 1, 0, 'v'}, {"debug", 1, 0, 'd'}, {"daemonize", 0, 0, 'D'}, @@ -111,7 +115,7 @@ static void handle_options(int argc, char **argv) {0, 0, 0, 0}, }; - c = getopt_long(argc, argv, "hi:v:d:Dm", + c = getopt_long(argc, argv, "hi:u:v:d:Dm", long_options, &option_index); if (c == -1) break; @@ -125,6 +129,9 @@ static void handle_options(int argc, char **argv) case 'i': gsmtap_ip = optarg; break; + case 'u': + vty_ip = optarg; + break; case 'v': vty_port = atoi(optarg); break; @@ -226,9 +233,9 @@ int main(int argc, char **argv) config_dir = dirname(config_dir); if (use_mncc_sock) - rc = l23_app_init(mncc_recv_socket, config_file, vty_port); + rc = l23_app_init(mncc_recv_socket, config_file, vty_ip, vty_port); else - rc = l23_app_init(NULL, config_file, vty_port); + rc = l23_app_init(NULL, config_file, vty_ip, vty_port); if (rc) exit(rc); diff --git a/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h b/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h index 2de4f19..65a1dd9 100644 --- a/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h +++ b/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h @@ -47,6 +47,7 @@ struct telnet_connection { }; int telnet_init(void *tall_ctx, void *priv, int port); +int telnet_init_dynif(void *tall_ctx, void *priv, const char *ip, int port); void telnet_exit(void); diff --git a/src/shared/libosmocore/src/vty/telnet_interface.c b/src/shared/libosmocore/src/vty/telnet_interface.c index 167acc1..d74ec09 100644 --- a/src/shared/libosmocore/src/vty/telnet_interface.c +++ b/src/shared/libosmocore/src/vty/telnet_interface.c @@ -18,6 +18,7 @@ * */ +#include #include #include #include @@ -101,6 +102,50 @@ int telnet_init(void *tall_ctx, void *priv, int port) return 0; } +int telnet_init_dynif(void *tall_ctx, void *priv, const char *ip, int port) +{ + struct sockaddr_in sock_addr; + int fd, rc, on = 1; + + tall_telnet_ctx = talloc_named_const(tall_ctx, 1, + "telnet_connection"); + + /* FIXME: use new socket.c code of libosmocore */ + fd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); + + if (fd < 0) { + LOGP(0, LOGL_ERROR, "Telnet interface socket creation failed\n"); + return fd; + } + + setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); + + memset(&sock_addr, 0, sizeof(sock_addr)); + sock_addr.sin_family = AF_INET; + sock_addr.sin_port = htons(port); + sock_addr.sin_addr.s_addr = inet_addr(ip); + + rc = bind(fd, (struct sockaddr*)&sock_addr, sizeof(sock_addr)); + if (rc < 0) { + LOGP(0, LOGL_ERROR, "Telnet interface failed to bind\n"); + close(fd); + return rc; + } + + rc = listen(fd, 0); + if (rc < 0) { + LOGP(0, LOGL_ERROR, "Telnet interface failed to listen\n"); + close(fd); + return rc; + } + + server_socket.data = priv; + server_socket.fd = fd; + osmo_fd_register(&server_socket); + + return 0; +} + extern struct host host; static void print_welcome(int fd) -- 1.7.1 From peter at stuge.se Tue Feb 21 13:09:25 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Feb 2012 14:09:25 +0100 Subject: [PATCH] Added option for mobile-app to bind to other interfaces than localhost. Signed-off-by: Tim Ehlers In-Reply-To: <1329826940-21171-1-git-send-email-osmocom@ehlers.info> References: <1329826940-21171-1-git-send-email-osmocom@ehlers.info> Message-ID: <20120221130925.27729.qmail@stuge.se> Tim Ehlers wrote: > +++ b/src/shared/libosmocore/src/vty/telnet_interface.c .. > @@ -101,6 +102,50 @@ int telnet_init(void *tall_ctx, void *priv, int port) > return 0; > } > > +int telnet_init_dynif(void *tall_ctx, void *priv, const char *ip, int port) > +{ > + struct sockaddr_in sock_addr; > + int fd, rc, on = 1; Rather than keeping the previous code around duplicated, perhaps the old telnet_init() can now call telnet_init_dynif() with 127.0.0.1 as ip parameter. Updating a commit is also easy. Make changes, then: git commit -a --amend -a tells git commit (like last time) that everything you have changed in the whole worktree (repository) should be committed. (Can also use git add file.c file2.c before git commit, in order to only mark some files, or even only some parts of files, for inclusion.) Thanks! //Peter From osmocom at ehlers.info Tue Feb 21 14:32:34 2012 From: osmocom at ehlers.info (Tim Ehlers) Date: Tue, 21 Feb 2012 15:32:34 +0100 Subject: [PATCH] Added option for mobile-app to bind to other interfaces than localhost. Message-ID: <1329834754-4970-1-git-send-email-osmocom@ehlers.info> Signed-off-by: Tim Ehlers --- .../layer23/include/osmocom/bb/common/l23_app.h | 1 + .../layer23/include/osmocom/bb/mobile/app_mobile.h | 2 +- src/host/layer23/src/common/main.c | 11 ++++++++++- src/host/layer23/src/mobile/app_mobile.c | 4 ++-- src/host/layer23/src/mobile/main.c | 13 ++++++++++--- .../include/osmocom/vty/telnet_interface.h | 1 + src/shared/libosmocore/src/vty/telnet_interface.c | 11 ++++++++++- 7 files changed, 35 insertions(+), 8 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/l23_app.h b/src/host/layer23/include/osmocom/bb/common/l23_app.h index e4c5d55..0b9994c 100644 --- a/src/host/layer23/include/osmocom/bb/common/l23_app.h +++ b/src/host/layer23/include/osmocom/bb/common/l23_app.h @@ -10,6 +10,7 @@ enum { L23_OPT_TAP = 4, L23_OPT_VTY = 8, L23_OPT_DBG = 16, + L23_OPT_VTYIP = 32, }; /* initialization, called once when starting the app, before entering diff --git a/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h b/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h index 4010a68..351dec3 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h +++ b/src/host/layer23/include/osmocom/bb/mobile/app_mobile.h @@ -4,7 +4,7 @@ char *config_dir; int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), - const char *config_file, uint16_t vty_port); + const char *config_file, const char *vty_ip, uint16_t vty_port); int l23_app_exit(void); int l23_app_work(int *quit); int mobile_delete(struct osmocom_ms *ms, int force); diff --git a/src/host/layer23/src/common/main.c b/src/host/layer23/src/common/main.c index eb47b26..59cee03 100644 --- a/src/host/layer23/src/common/main.c +++ b/src/host/layer23/src/common/main.c @@ -56,6 +56,7 @@ static char *sap_socket_path = "/tmp/osmocom_sap"; struct llist_head ms_list; static struct osmocom_ms *ms = NULL; static char *gsmtap_ip = NULL; +static char *vty_ip = "127.0.0.1"; unsigned short vty_port = 4247; int (*l23_app_work) (struct osmocom_ms *ms) = NULL; @@ -106,6 +107,10 @@ static void print_help() if (options & L23_OPT_DBG) printf(" -d --debug Change debug flags.\n"); + if (options & L23_OPT_VTYIP) + printf(" -u --vty-ip The VTY IP to bind telnet to. " + "(default %s)\n", vty_ip); + if (app && app->cfg_print_help) app->cfg_print_help(); } @@ -122,13 +127,14 @@ static void build_config(char **opt, struct option **option) {"sap", 1, 0, 'S'}, {"arfcn", 1, 0, 'a'}, {"gsmtap-ip", 1, 0, 'i'}, + {"vty-ip", 1, 0, 'u'}, {"vty-port", 1, 0, 'v'}, {"debug", 1, 0, 'd'}, }; app = l23_app_info(); - *opt = talloc_asprintf(l23_ctx, "hs:S:a:i:v:d:%s", + *opt = talloc_asprintf(l23_ctx, "hs:S:a:i:v:d:u:%s", app && app->getopt_string ? app->getopt_string : ""); len = ARRAY_SIZE(long_options); @@ -174,6 +180,9 @@ static void handle_options(int argc, char **argv) case 'i': gsmtap_ip = optarg; break; + case 'u': + vty_ip = optarg; + break; case 'v': vty_port = atoi(optarg); break; diff --git a/src/host/layer23/src/mobile/app_mobile.c b/src/host/layer23/src/mobile/app_mobile.c index da388b2..d911ab3 100644 --- a/src/host/layer23/src/mobile/app_mobile.c +++ b/src/host/layer23/src/mobile/app_mobile.c @@ -352,7 +352,7 @@ static struct vty_app_info vty_info = { /* global init */ int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), - const char *config_file, uint16_t vty_port) + const char *config_file, const char *vty_ip, uint16_t vty_port) { struct telnet_connection dummy_conn; int rc = 0; @@ -376,7 +376,7 @@ int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), } } vty_reading = 0; - telnet_init(l23_ctx, NULL, vty_port); + telnet_init_dynif(l23_ctx, NULL, vty_ip, vty_port); if (rc < 0) return rc; printf("VTY available on port %u.\n", vty_port); diff --git a/src/host/layer23/src/mobile/main.c b/src/host/layer23/src/mobile/main.c index 89c9b94..312bcd6 100644 --- a/src/host/layer23/src/mobile/main.c +++ b/src/host/layer23/src/mobile/main.c @@ -52,6 +52,7 @@ void *l23_ctx = NULL; struct llist_head ms_list; static char *gsmtap_ip = 0; struct gsmtap_inst *gsmtap_inst = NULL; +static char *vty_ip = "127.0.0.1"; unsigned short vty_port = 4247; int debug_set = 0; char *config_dir = NULL; @@ -88,6 +89,8 @@ static void print_help() printf(" Some help...\n"); printf(" -h --help this text\n"); printf(" -i --gsmtap-ip The destination IP used for GSMTAP.\n"); + printf(" -u --vty-ip The VTY IP to telnet to. " + "(default %s)\n", vty_ip); printf(" -v --vty-port The VTY port number to telnet to. " "(default %u)\n", vty_port); printf(" -d --debug Change debug flags. default: %s\n", @@ -104,6 +107,7 @@ static void handle_options(int argc, char **argv) static struct option long_options[] = { {"help", 0, 0, 'h'}, {"gsmtap-ip", 1, 0, 'i'}, + {"vty-ip", 1, 0, 'u'}, {"vty-port", 1, 0, 'v'}, {"debug", 1, 0, 'd'}, {"daemonize", 0, 0, 'D'}, @@ -111,7 +115,7 @@ static void handle_options(int argc, char **argv) {0, 0, 0, 0}, }; - c = getopt_long(argc, argv, "hi:v:d:Dm", + c = getopt_long(argc, argv, "hi:u:v:d:Dm", long_options, &option_index); if (c == -1) break; @@ -125,6 +129,9 @@ static void handle_options(int argc, char **argv) case 'i': gsmtap_ip = optarg; break; + case 'u': + vty_ip = optarg; + break; case 'v': vty_port = atoi(optarg); break; @@ -226,9 +233,9 @@ int main(int argc, char **argv) config_dir = dirname(config_dir); if (use_mncc_sock) - rc = l23_app_init(mncc_recv_socket, config_file, vty_port); + rc = l23_app_init(mncc_recv_socket, config_file, vty_ip, vty_port); else - rc = l23_app_init(NULL, config_file, vty_port); + rc = l23_app_init(NULL, config_file, vty_ip, vty_port); if (rc) exit(rc); diff --git a/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h b/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h index 2de4f19..65a1dd9 100644 --- a/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h +++ b/src/shared/libosmocore/include/osmocom/vty/telnet_interface.h @@ -47,6 +47,7 @@ struct telnet_connection { }; int telnet_init(void *tall_ctx, void *priv, int port); +int telnet_init_dynif(void *tall_ctx, void *priv, const char *ip, int port); void telnet_exit(void); diff --git a/src/shared/libosmocore/src/vty/telnet_interface.c b/src/shared/libosmocore/src/vty/telnet_interface.c index 167acc1..bbc0791 100644 --- a/src/shared/libosmocore/src/vty/telnet_interface.c +++ b/src/shared/libosmocore/src/vty/telnet_interface.c @@ -18,6 +18,7 @@ * */ +#include #include #include #include @@ -59,6 +60,14 @@ static struct osmo_fd server_socket = { */ int telnet_init(void *tall_ctx, void *priv, int port) { + int rc; + rc = telnet_init_dynif(tall_ctx, priv, "127.0.0.1", port); + + return rc; +} + +int telnet_init_dynif(void *tall_ctx, void *priv, const char *ip, int port) +{ struct sockaddr_in sock_addr; int fd, rc, on = 1; @@ -78,7 +87,7 @@ int telnet_init(void *tall_ctx, void *priv, int port) memset(&sock_addr, 0, sizeof(sock_addr)); sock_addr.sin_family = AF_INET; sock_addr.sin_port = htons(port); - sock_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); + sock_addr.sin_addr.s_addr = inet_addr(ip); rc = bind(fd, (struct sockaddr*)&sock_addr, sizeof(sock_addr)); if (rc < 0) { -- 1.7.1 From laforge at gnumonks.org Tue Feb 21 15:55:37 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Feb 2012 16:55:37 +0100 Subject: [PATCH] Added option for mobile-app to bind to other interfaces than localhost. In-Reply-To: <1329834754-4970-1-git-send-email-osmocom@ehlers.info> References: <1329834754-4970-1-git-send-email-osmocom@ehlers.info> Message-ID: <20120221155537.GC29148@prithivi.gnumonks.org> Patch looks fine to me, On Tue, Feb 21, 2012 at 03:32:34PM +0100, Tim Ehlers wrote: > int telnet_init(void *tall_ctx, void *priv, int port) > { > + int rc; > + rc = telnet_init_dynif(tall_ctx, priv, "127.0.0.1", port); > + > + return rc; > +} erm, as far as I can tell, there's no point in having the rc variable, it could simply be "return telnet_init_dynif(...)". > - sock_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); > + sock_addr.sin_addr.s_addr = inet_addr(ip); This is still ipv4-only and not using the libosmocore/socket.c code as I suggested. However, I think we can first merge your current patch. Hoepfully somebody can contribute a conversion to libosmocore/socket.c API, which would automatically make ipv6 work, too. I'm currently travelling and don't have time to test it right now. I home one of the other developers with commit access will be able to try it. Thanks. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ondra2000 at centrum.cz Wed Feb 22 12:06:45 2012 From: ondra2000 at centrum.cz (ondra2000 at centrum.cz) Date: Wed, 22 Feb 2012 13:06:45 +0100 Subject: set sm-RP-OA in gsm411_sms.c Message-ID: <20120222130645.7FCB9700@centrum.cz> Hello, I need to set originating address in MO SMS (SM-RP-OA)... I found this field in src/host/layer23/src/mobile/gsm411_sms.c --> /* no orig Address */ data = (uint8_t *)msgb_put(msg, 1); data[0] = 0x00; /* originator length == 0 */ Field has 0 length. Can anybody pleas help me how to set this field to some MSISDN...I know that there must be some fields for TON,NPI, number ... but I don't know how to write these fields into source code... With this change i want to find out how MSC behave when is field SM-RP-OA set to some real MSISDN. Thank you! Andrew From ondra2000 at centrum.cz Wed Feb 22 12:11:06 2012 From: ondra2000 at centrum.cz (ondra2000 at centrum.cz) Date: Wed, 22 Feb 2012 13:11:06 +0100 Subject: set sm-rp-oa in gsm411_sms.c Message-ID: <20120222131106.94E6F476@centrum.cz> Hello, I need to set originating address in MO SMS (SM submit, SM-RP-OA field)... I found this field in src/host/layer23/src/mobile/gsm411_sms.c --> /* no orig Address */ data = (uint8_t *)msgb_put(msg, 1); data[0] = 0x00; /* originator length == 0 */ Field has 0 length. Can anybody pleas help me how to set this field to some MSISDN...I know that there must be some fields for TON,NPI, number ... but I don't know how to write these fields into source code... With this change i want to find out how MSC behave when is field SM-RP-OA set to some real MSISDN. Thank you! Andrew From t-osmocombb at tobias.org Wed Feb 22 13:27:35 2012 From: t-osmocombb at tobias.org (Tobias Engel) Date: Wed, 22 Feb 2012 14:27:35 +0100 Subject: set sm-rp-oa in gsm411_sms.c In-Reply-To: <20120222131106.94E6F476@centrum.cz> References: <20120222131106.94E6F476@centrum.cz> Message-ID: <4F44ED47.7080109@tobias.org> Hi Andrew, > I need to set originating address in MO SMS (SM submit, SM-RP-OA field)... I found this field in src/host/layer23/src/mobile/gsm411_sms.c --> > > /* no orig Address */ > data = (uint8_t *)msgb_put(msg, 1); > data[0] = 0x00; /* originator length == 0 */ > > Field has 0 length. Can anybody pleas help me how to set this field to some MSISDN...I know that there must be some fields for TON,NPI, number ... but I don't know how to write these fields into source code... > With this change i want to find out how MSC behave when is field SM-RP-OA set to some real MSISDN. the coding of the originator address element is specified in 3GPP TS 24.011 8.2.5.1 and the TON/NPI fields in 3GPP TS 24.008 10.5.4.7. Let us know what you find out :) -Tobias From ondra2000 at centrum.cz Wed Feb 22 15:22:42 2012 From: ondra2000 at centrum.cz (ondra2000 at centrum.cz) Date: Wed, 22 Feb 2012 16:22:42 +0100 Subject: set sm-rp-oa in gsm411_sms.c In-Reply-To: <4F44ED47.7080109@tobias.org> References: <20120222131106.94E6F476@centrum.cz> <4F44ED47.7080109@tobias.org> Message-ID: <20120222162242.8CD52B4F@centrum.cz> Thanks for reply! So if my originating address is for example 0xAAAAAAAAh (complete sm-rp-OA with NPI,TON etc.) then into the c file I only put: data = (uint8_t *)msgb_put(msg, 1); data[0] = 0xAAAAAAAA; /* originator address*/ Am I right? Thanks Andrew ______________________________________________________________ > Od: "Tobias Engel" > Komu: > Datum: 22.02.2012 14:30 > P?edm?t: Re: set sm-rp-oa in gsm411_sms.c > >Hi Andrew, > >> I need to set originating address in MO SMS (SM submit, SM-RP-OA field)... I found this field in src/host/layer23/src/mobile/gsm411_sms.c --> >> >> /* no orig Address */ >> data = (uint8_t *)msgb_put(msg, 1); >> data[0] = 0x00; /* originator length == 0 */ >> >> Field has 0 length. Can anybody pleas help me how to set this field to some MSISDN...I know that there must be some fields for TON,NPI, number ... but I don't know how to write these fields into source code... >> With this change i want to find out how MSC behave when is field SM-RP-OA set to some real MSISDN. > >the coding of the originator address element is specified in 3GPP TS >24.011 8.2.5.1 and the TON/NPI fields in 3GPP TS 24.008 10.5.4.7. > >Let us know what you find out :) > >-Tobias > > From GNUtoo at no-log.org Sat Feb 25 20:34:40 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Sat, 25 Feb 2012 21:34:40 +0100 Subject: unbreak nuttx-bb and add support for compal_e88 phones Message-ID: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> Hi, Alan Carvalho de Assis and me have been working on making nuttx-bb work on our phones( I've a gta02 and he has a Motorola W220) and here are the patches(against nuttx-bb). To try it, clone nuttx-bb and osmocom-bb, put it in the same directory and keep the name of the osmocom-bb directory. Then put the gnuarm(for 64bit) or the codesourcery(for 32bit) in your path(there is a problem with gnuarm for 32bit). Compile osmocom-bb as usual(cd osmocom-bb/src && make). Then go in nuttx-bb directory and do: cd nuttx/tools/ ./configure.sh compal_e88/nsh #for for compal_e88( gta02 and Motorola W220). ./configure.sh compal_e99/nsh #we need testers for compal_e99, we don't have one. cd ../ make That will create a nuttx.bin, load it as usual(like any other firmware for your calypso). Then the following will appear: Finished, sent 63 blocks in total Received block ack from phone Sending checksum: 0x66 Checksum on phone side matches, let's branch to your code Branching to 0x00820000 Received branch ack, your code is running now! NuttShell (NSH) To send commands to the shell you need to run loadwriter.py that is included in the source code at: nuttx/drivers/sercomm/loadwriter.py The list of commands can be found by typing help. Denis. From GNUtoo at no-log.org Sat Feb 25 20:34:41 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Sat, 25 Feb 2012 21:34:41 +0100 Subject: [nuttx-bb][PATCH 1/3] Fix console by sending chunk blocks lesser than 32 bytes In-Reply-To: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> Message-ID: <1330202083-5399-2-git-send-email-GNUtoo@no-log.org> From: Alan Carvalho de Assis We cannot send a big chunk of bytes to sercomm_puts because .txready on NuttX doesn't detect when "UART" finished sending data, then data are lost. An work-around to fix it is sending less bytes and putting a delay after each transfer. Signed-off-by: Alan Carvalho de Assis --- nuttx/drivers/sercomm/console.c | 23 ++++++++++++++++++----- 1 files changed, 18 insertions(+), 5 deletions(-) diff --git a/nuttx/drivers/sercomm/console.c b/nuttx/drivers/sercomm/console.c index 09ce469..1b96acf 100644 --- a/nuttx/drivers/sercomm/console.c +++ b/nuttx/drivers/sercomm/console.c @@ -106,14 +106,27 @@ static ssize_t sc_console_read(file_t *filep, FAR char *buffer, size_t buflen) } /* XXX: redirect to old Osmocom-BB comm/sercomm_cons.c -> 2 buffers */ -extern int sercomm_write(void *file, const char *s, const int len); +extern int sercomm_puts(const char *s); static ssize_t sc_console_write(file_t *filep, FAR const char *buffer, size_t buflen) { - int ret = sercomm_write(filep, buffer, buflen); - if(ret < 0) - return ret; + int i, cnt; + char dstbuf[32]; + + if (buflen >= 31) + cnt = 31; else - return buflen; + cnt = buflen; + + memcpy(dstbuf, buffer, cnt); + dstbuf[cnt] = '\0'; + + /* print part of our buffer */ + sercomm_puts(dstbuf); + + /* wait a little bit to get data transfered */ + up_mdelay(1); + + return cnt; } /* Forward ioctl to uart driver */ -- 1.7.4.1 From acassis at gmail.com Sat Feb 25 21:35:03 2012 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Sat, 25 Feb 2012 19:35:03 -0200 Subject: [nuttx-bb][PATCH 1/3] Fix console by sending chunk blocks lesser than 32 bytes In-Reply-To: <1330202083-5399-2-git-send-email-GNUtoo@no-log.org> References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> <1330202083-5399-2-git-send-email-GNUtoo@no-log.org> Message-ID: On 2/25/12, Denis 'GNUtoo' Carikli wrote: snip > + > + if (buflen >= 31) > + cnt = 31; > else > - return buflen; > + cnt = buflen; > + I could simplify this if/else by: cnt = buflen & 0x1F; but I think it will not be readable for other people. Best Regards, Alan From 246tnt at gmail.com Sat Feb 25 21:59:06 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 25 Feb 2012 22:59:06 +0100 Subject: [nuttx-bb][PATCH 1/3] Fix console by sending chunk blocks lesser than 32 bytes In-Reply-To: References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> <1330202083-5399-2-git-send-email-GNUtoo@no-log.org> Message-ID: > > + if (buflen >= 31) > > + cnt = 31; > > else > > - return buflen; > > + cnt = buflen; > > + > > I could simplify this if/else by: > > cnt = buflen & 0x1F; > > but I think it will not be readable for other people. > > > + It would also be wrong ... 32 & 0x1F = 0 ... Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From acassis at gmail.com Sun Feb 26 11:16:56 2012 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Sun, 26 Feb 2012 08:16:56 -0300 Subject: [nuttx-bb][PATCH 1/3] Fix console by sending chunk blocks lesser than 32 bytes In-Reply-To: References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> <1330202083-5399-2-git-send-email-GNUtoo@no-log.org> Message-ID: On 2/25/12, Sylvain Munaut <246tnt at gmail.com> wrote: >> cnt = buflen & 0x1F; >> >> but I think it will not be readable for other people. >> >> > + > > It would also be wrong ... > > 32 & 0x1F = 0 ... > Yes, my fault, it should saturate on 31 if buflen bigger than 31. So, let us keep this if/else. BR, Alan From GNUtoo at no-log.org Sat Feb 25 20:34:42 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Sat, 25 Feb 2012 21:34:42 +0100 Subject: [nuttx-bb][PATCH 2/3] Add compal_e88 for phones like the gta02 modem and the Motorola W220 In-Reply-To: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> Message-ID: <1330202083-5399-3-git-send-email-GNUtoo@no-log.org> The compal_e88 directory contains a fixed linking script to make it work romloader compatibles phones. Signed-off-by: Denis 'GNUtoo' Carikli --- .../calypsotest/Make.defs | 2 +- .../calypsotest/appconfig | 0 .../calypsotest/defconfig | 6 +++--- .../ostest => compal_e88/calypsotest}/setenv.sh | 0 .../{compal_e99 => compal_e88}/include/board.h | 0 nuttx/configs/{compal_e99 => compal_e88}/ld.script | 20 +++++++++++--------- .../{compal_e99 => compal_e88}/nsh/Make.defs | 0 .../{compal_e99 => compal_e88}/nsh/appconfig | 0 .../{compal_e99 => compal_e88}/nsh/defconfig | 4 ++-- .../{compal_e99 => compal_e88/nsh}/ld.script | 20 +++++++++++--------- .../configs/{c5471evm => compal_e88}/nsh/setenv.sh | 0 .../{compal_e99 => compal_e88}/ostest/Make.defs | 2 +- .../{c5471evm => compal_e88}/ostest/appconfig | 0 .../{compal_e99 => compal_e88}/ostest/defconfig | 6 +++--- .../{c5471evm => compal_e88}/ostest/setenv.sh | 0 nuttx/configs/compal_e88/src/Make.dep | 1 + .../{compal_e99 => compal_e88}/src/Makefile | 2 +- .../configs/{compal_e99 => compal_e88}/src/dummy.c | 0 18 files changed, 34 insertions(+), 29 deletions(-) copy nuttx/configs/{compal_e99 => compal_e88}/calypsotest/Make.defs (99%) copy nuttx/configs/{compal_e99 => compal_e88}/calypsotest/appconfig (100%) copy nuttx/configs/{compal_e99 => compal_e88}/calypsotest/defconfig (99%) copy nuttx/configs/{c5471evm/ostest => compal_e88/calypsotest}/setenv.sh (100%) copy nuttx/configs/{compal_e99 => compal_e88}/include/board.h (100%) copy nuttx/configs/{compal_e99 => compal_e88}/ld.script (91%) copy nuttx/configs/{compal_e99 => compal_e88}/nsh/Make.defs (100%) copy nuttx/configs/{compal_e99 => compal_e88}/nsh/appconfig (100%) copy nuttx/configs/{compal_e99 => compal_e88}/nsh/defconfig (99%) copy nuttx/configs/{compal_e99 => compal_e88/nsh}/ld.script (91%) copy nuttx/configs/{c5471evm => compal_e88}/nsh/setenv.sh (100%) copy nuttx/configs/{compal_e99 => compal_e88}/ostest/Make.defs (99%) copy nuttx/configs/{c5471evm => compal_e88}/ostest/appconfig (100%) copy nuttx/configs/{compal_e99 => compal_e88}/ostest/defconfig (99%) copy nuttx/configs/{c5471evm => compal_e88}/ostest/setenv.sh (100%) create mode 100644 nuttx/configs/compal_e88/src/.depend create mode 100644 nuttx/configs/compal_e88/src/Make.dep copy nuttx/configs/{compal_e99 => compal_e88}/src/Makefile (98%) copy nuttx/configs/{compal_e99 => compal_e88}/src/dummy.c (100%) diff --git a/nuttx/configs/compal_e99/calypsotest/Make.defs b/nuttx/configs/compal_e88/calypsotest/Make.defs similarity index 99% copy from nuttx/configs/compal_e99/calypsotest/Make.defs copy to nuttx/configs/compal_e88/calypsotest/Make.defs index 405dbd2..4099ccd 100644 --- a/nuttx/configs/compal_e99/calypsotest/Make.defs +++ b/nuttx/configs/compal_e88/calypsotest/Make.defs @@ -1,5 +1,5 @@ ############################################################################ -# configs/compal_e99/ostest/Make.defs +# configs/compal_e88/ostest/Make.defs # # Copyright (C) 2007, 2008, 2011 Gregory Nutt. All rights reserved. # Author: Gregory Nutt diff --git a/nuttx/configs/compal_e99/calypsotest/appconfig b/nuttx/configs/compal_e88/calypsotest/appconfig similarity index 100% copy from nuttx/configs/compal_e99/calypsotest/appconfig copy to nuttx/configs/compal_e88/calypsotest/appconfig diff --git a/nuttx/configs/compal_e99/calypsotest/defconfig b/nuttx/configs/compal_e88/calypsotest/defconfig similarity index 99% copy from nuttx/configs/compal_e99/calypsotest/defconfig copy to nuttx/configs/compal_e88/calypsotest/defconfig index e30ae36..8ac4bb6 100644 --- a/nuttx/configs/compal_e99/calypsotest/defconfig +++ b/nuttx/configs/compal_e88/calypsotest/defconfig @@ -1,5 +1,5 @@ ############################################################################ -# configs/compal_e99/ostest/defconfig +# configs/compal_e88/ostest/defconfig # # Copyright (C) 2007-2011 Gregory Nutt. All rights reserved. # Author: Gregory Nutt @@ -64,8 +64,8 @@ CONFIG_ARCH_ARM=y CONFIG_ARCH_ARM7TDMI=y CONFIG_ARCH_CHIP=calypso CONFIG_ARCH_CHIP_CALYPSO=y -CONFIG_ARCH_BOARD=compal_e99 -CONFIG_ARCH_BOARD_COMPALE99=y +CONFIG_ARCH_BOARD=compal_e88 +CONFIG_ARCH_BOARD_COMPALE88=y CONFIG_BOARD_LOOPSPERMSEC=1250 CONFIG_ROM_VECTORS=n CONFIG_DRAM_END=0x00840000 diff --git a/nuttx/configs/c5471evm/ostest/setenv.sh b/nuttx/configs/compal_e88/calypsotest/setenv.sh similarity index 100% copy from nuttx/configs/c5471evm/ostest/setenv.sh copy to nuttx/configs/compal_e88/calypsotest/setenv.sh diff --git a/nuttx/configs/compal_e99/include/board.h b/nuttx/configs/compal_e88/include/board.h similarity index 100% copy from nuttx/configs/compal_e99/include/board.h copy to nuttx/configs/compal_e88/include/board.h diff --git a/nuttx/configs/compal_e99/ld.script b/nuttx/configs/compal_e88/ld.script similarity index 91% copy from nuttx/configs/compal_e99/ld.script copy to nuttx/configs/compal_e88/ld.script index 07f1ab0..838aad2 100644 --- a/nuttx/configs/compal_e99/ld.script +++ b/nuttx/configs/compal_e88/ld.script @@ -11,10 +11,12 @@ OUTPUT_ARCH(arm) ENTRY(__start) MEMORY { + /* 0x800000-0x83ffff */ /* compal-loaded binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00010000 + LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000 + TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00010000 /* compal-loaded binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x00810000, LENGTH = 0x00010000 + IRAM (rw) : ORIGIN = 0x00830000, LENGTH = 0x0000ffff } SECTIONS { @@ -32,7 +34,7 @@ SECTIONS PROVIDE(__start = .); KEEP(*(.text.start)) *(.text.start) - } > LRAM + } > TRAM /* exception vectors from 0x80001c to 0x800034 */ .text.exceptions 0x80001c : AT (LOADADDR(.text.start) + SIZEOF(.text.start)) { @@ -53,7 +55,7 @@ SECTIONS /* gcc voodoo */ *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) . = ALIGN(4); - } > LRAM + } > TRAM PROVIDE(_text_start = LOADADDR(.text)); PROVIDE(_text_end = LOADADDR(.text) + SIZEOF(.text)); @@ -65,7 +67,7 @@ SECTIONS KEEP(*(SORT(.ctors))) /* end of list */ LONG(0) - } > LRAM + } > TRAM PROVIDE(_ctor_start = LOADADDR(.ctors)); PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); @@ -77,7 +79,7 @@ SECTIONS KEEP(*(SORT(.dtors))) /* end of list */ LONG(0) - } > LRAM + } > TRAM PROVIDE(_dtor_start = LOADADDR(.dtors)); PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); @@ -85,7 +87,7 @@ SECTIONS . = ALIGN(4); .rodata : { *(.rodata*) - } > LRAM + } > TRAM PROVIDE(_rodata_start = LOADADDR(.rodata)); PROVIDE(_rodata_end = LOADADDR(.rodata) + SIZEOF(.rodata)); @@ -93,7 +95,7 @@ SECTIONS . = ALIGN(4); .data : { *(.data) - } > LRAM + } > TRAM PROVIDE(_data_start = LOADADDR(.data)); PROVIDE(_data_end = LOADADDR(.data) + SIZEOF(.data)); @@ -102,7 +104,7 @@ SECTIONS .got : { *(.got) *(.got.plt) *(.igot.plt) *(.got) *(.igot) - } > LRAM + } > TRAM PROVIDE(_got_start = LOADADDR(.got)); PROVIDE(_got_end = LOADADDR(.got) + SIZEOF(.got)); diff --git a/nuttx/configs/compal_e99/nsh/Make.defs b/nuttx/configs/compal_e88/nsh/Make.defs similarity index 100% copy from nuttx/configs/compal_e99/nsh/Make.defs copy to nuttx/configs/compal_e88/nsh/Make.defs diff --git a/nuttx/configs/compal_e99/nsh/appconfig b/nuttx/configs/compal_e88/nsh/appconfig similarity index 100% copy from nuttx/configs/compal_e99/nsh/appconfig copy to nuttx/configs/compal_e88/nsh/appconfig diff --git a/nuttx/configs/compal_e99/nsh/defconfig b/nuttx/configs/compal_e88/nsh/defconfig similarity index 99% copy from nuttx/configs/compal_e99/nsh/defconfig copy to nuttx/configs/compal_e88/nsh/defconfig index 946c9cf..ebec6f0 100644 --- a/nuttx/configs/compal_e99/nsh/defconfig +++ b/nuttx/configs/compal_e88/nsh/defconfig @@ -64,8 +64,8 @@ CONFIG_ARCH_ARM=y CONFIG_ARCH_ARM7TDMI=y CONFIG_ARCH_CHIP=calypso CONFIG_ARCH_CHIP_CALYPSO=y -CONFIG_ARCH_BOARD=compal_e99 -CONFIG_ARCH_BOARD_COMPALE99=y +CONFIG_ARCH_BOARD=compal_e88 +CONFIG_ARCH_BOARD_COMPALE88=y CONFIG_BOARD_LOOPSPERMSEC=1250 CONFIG_ROM_VECTORS=n CONFIG_DRAM_END=0x00840000 diff --git a/nuttx/configs/compal_e99/ld.script b/nuttx/configs/compal_e88/nsh/ld.script similarity index 91% copy from nuttx/configs/compal_e99/ld.script copy to nuttx/configs/compal_e88/nsh/ld.script index 07f1ab0..838aad2 100644 --- a/nuttx/configs/compal_e99/ld.script +++ b/nuttx/configs/compal_e88/nsh/ld.script @@ -11,10 +11,12 @@ OUTPUT_ARCH(arm) ENTRY(__start) MEMORY { + /* 0x800000-0x83ffff */ /* compal-loaded binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00010000 + LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000 + TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00010000 /* compal-loaded binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x00810000, LENGTH = 0x00010000 + IRAM (rw) : ORIGIN = 0x00830000, LENGTH = 0x0000ffff } SECTIONS { @@ -32,7 +34,7 @@ SECTIONS PROVIDE(__start = .); KEEP(*(.text.start)) *(.text.start) - } > LRAM + } > TRAM /* exception vectors from 0x80001c to 0x800034 */ .text.exceptions 0x80001c : AT (LOADADDR(.text.start) + SIZEOF(.text.start)) { @@ -53,7 +55,7 @@ SECTIONS /* gcc voodoo */ *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) . = ALIGN(4); - } > LRAM + } > TRAM PROVIDE(_text_start = LOADADDR(.text)); PROVIDE(_text_end = LOADADDR(.text) + SIZEOF(.text)); @@ -65,7 +67,7 @@ SECTIONS KEEP(*(SORT(.ctors))) /* end of list */ LONG(0) - } > LRAM + } > TRAM PROVIDE(_ctor_start = LOADADDR(.ctors)); PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); @@ -77,7 +79,7 @@ SECTIONS KEEP(*(SORT(.dtors))) /* end of list */ LONG(0) - } > LRAM + } > TRAM PROVIDE(_dtor_start = LOADADDR(.dtors)); PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); @@ -85,7 +87,7 @@ SECTIONS . = ALIGN(4); .rodata : { *(.rodata*) - } > LRAM + } > TRAM PROVIDE(_rodata_start = LOADADDR(.rodata)); PROVIDE(_rodata_end = LOADADDR(.rodata) + SIZEOF(.rodata)); @@ -93,7 +95,7 @@ SECTIONS . = ALIGN(4); .data : { *(.data) - } > LRAM + } > TRAM PROVIDE(_data_start = LOADADDR(.data)); PROVIDE(_data_end = LOADADDR(.data) + SIZEOF(.data)); @@ -102,7 +104,7 @@ SECTIONS .got : { *(.got) *(.got.plt) *(.igot.plt) *(.got) *(.igot) - } > LRAM + } > TRAM PROVIDE(_got_start = LOADADDR(.got)); PROVIDE(_got_end = LOADADDR(.got) + SIZEOF(.got)); diff --git a/nuttx/configs/c5471evm/nsh/setenv.sh b/nuttx/configs/compal_e88/nsh/setenv.sh similarity index 100% copy from nuttx/configs/c5471evm/nsh/setenv.sh copy to nuttx/configs/compal_e88/nsh/setenv.sh diff --git a/nuttx/configs/compal_e99/ostest/Make.defs b/nuttx/configs/compal_e88/ostest/Make.defs similarity index 99% copy from nuttx/configs/compal_e99/ostest/Make.defs copy to nuttx/configs/compal_e88/ostest/Make.defs index 06ef3d4..c887dd0 100644 --- a/nuttx/configs/compal_e99/ostest/Make.defs +++ b/nuttx/configs/compal_e88/ostest/Make.defs @@ -1,5 +1,5 @@ ############################################################################ -# configs/compal_e99/ostest/Make.defs +# configs/compal_e88/ostest/Make.defs # # Copyright (C) 2007, 2008, 2011 Gregory Nutt. All rights reserved. # Author: Gregory Nutt diff --git a/nuttx/configs/c5471evm/ostest/appconfig b/nuttx/configs/compal_e88/ostest/appconfig similarity index 100% copy from nuttx/configs/c5471evm/ostest/appconfig copy to nuttx/configs/compal_e88/ostest/appconfig diff --git a/nuttx/configs/compal_e99/ostest/defconfig b/nuttx/configs/compal_e88/ostest/defconfig similarity index 99% copy from nuttx/configs/compal_e99/ostest/defconfig copy to nuttx/configs/compal_e88/ostest/defconfig index 12c365e..1b5ded9 100644 --- a/nuttx/configs/compal_e99/ostest/defconfig +++ b/nuttx/configs/compal_e88/ostest/defconfig @@ -1,5 +1,5 @@ ############################################################################ -# configs/compal_e99/ostest/defconfig +# configs/compal_e88/ostest/defconfig # # Copyright (C) 2007-2011 Gregory Nutt. All rights reserved. # Author: Gregory Nutt @@ -64,8 +64,8 @@ CONFIG_ARCH_ARM=y CONFIG_ARCH_ARM7TDMI=y CONFIG_ARCH_CHIP=calypso CONFIG_ARCH_CHIP_CALYPSO=y -CONFIG_ARCH_BOARD=compal_e99 -CONFIG_ARCH_BOARD_COMPALE99=y +CONFIG_ARCH_BOARD=compal_e88 +CONFIG_ARCH_BOARD_COMPALE88=y CONFIG_BOARD_LOOPSPERMSEC=1250 CONFIG_ROM_VECTORS=n CONFIG_DRAM_END=0x00840000 diff --git a/nuttx/configs/c5471evm/ostest/setenv.sh b/nuttx/configs/compal_e88/ostest/setenv.sh similarity index 100% copy from nuttx/configs/c5471evm/ostest/setenv.sh copy to nuttx/configs/compal_e88/ostest/setenv.sh diff --git a/nuttx/configs/compal_e88/src/.depend b/nuttx/configs/compal_e88/src/.depend new file mode 100644 index 0000000..e69de29 diff --git a/nuttx/configs/compal_e88/src/Make.dep b/nuttx/configs/compal_e88/src/Make.dep new file mode 100644 index 0000000..b8378cf --- /dev/null +++ b/nuttx/configs/compal_e88/src/Make.dep @@ -0,0 +1 @@ +dummy.o: dummy.c diff --git a/nuttx/configs/compal_e99/src/Makefile b/nuttx/configs/compal_e88/src/Makefile similarity index 98% copy from nuttx/configs/compal_e99/src/Makefile copy to nuttx/configs/compal_e88/src/Makefile index 2160ea3..851a603 100644 --- a/nuttx/configs/compal_e99/src/Makefile +++ b/nuttx/configs/compal_e88/src/Makefile @@ -1,5 +1,5 @@ ############################################################################ -# configs/compal_e99/src/Makefile +# configs/compal_e88/src/Makefile # # Copyright (C) 2007, 2008 Gregory Nutt. All rights reserved. # Author: Gregory Nutt diff --git a/nuttx/configs/compal_e99/src/dummy.c b/nuttx/configs/compal_e88/src/dummy.c similarity index 100% copy from nuttx/configs/compal_e99/src/dummy.c copy to nuttx/configs/compal_e88/src/dummy.c -- 1.7.4.1 From GNUtoo at no-log.org Sat Feb 25 20:34:43 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Sat, 25 Feb 2012 21:34:43 +0100 Subject: [nuttx-bb][PATCH 3/3] Disable watchdog only for compal_e99 In-Reply-To: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> Message-ID: <1330202083-5399-4-git-send-email-GNUtoo@no-log.org> Without that fix some compal_e88 phones like the Motorola W220 don't print the "NuttShell (NSH)" initial message. Signed-off-by: Denis 'GNUtoo' Carikli --- nuttx/arch/arm/src/calypso/calypso_heap.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/nuttx/arch/arm/src/calypso/calypso_heap.c b/nuttx/arch/arm/src/calypso/calypso_heap.c index d35a76f..7ae0490 100644 --- a/nuttx/arch/arm/src/calypso/calypso_heap.c +++ b/nuttx/arch/arm/src/calypso/calypso_heap.c @@ -60,9 +60,11 @@ void up_addregion(void) { +#ifdef CONFIG_ARCH_BOARD_COMPALE99 /* Disable watchdog in first non-common function */ wdog_enable(0); - +#endif + // XXX: change to initialization of extern memory with save defaults /* Configure memory interface */ calypso_mem_cfg(CALYPSO_nCS0, 3, CALYPSO_MEM_16bit, 1); -- 1.7.4.1 From laforge at gnumonks.org Sat Feb 25 22:28:01 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 25 Feb 2012 23:28:01 +0100 Subject: unbreak nuttx-bb and add support for compal_e88 phones In-Reply-To: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> References: <1330202083-5399-1-git-send-email-GNUtoo@no-log.org> Message-ID: <20120225222801.GN724@prithivi.gnumonks.org> Hi Denis, thansk a lot for your work on the nuttx-bb code base. As there isn't really any other activity in the repository, I'm happy to give you direct git write access. If you'd like that, please send me a SSHv2 public key. On Sat, Feb 25, 2012 at 09:34:40PM +0100, Denis 'GNUtoo' Carikli wrote: > ./configure.sh compal_e99/nsh #we need testers for compal_e99, we don't have one. If you'd like to test E99, I can send you guys one or two new C155 for free. Just let me know the shipping address in private mail. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From GNUtoo at no-log.org Tue Feb 28 21:17:37 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Tue, 28 Feb 2012 22:17:37 +0100 Subject: [nuttx-bb] how to integrate nuttx-bb into upstream nuttx. Message-ID: <201202282217.37832.GNUtoo@no-log.org> Hi, Nuttx is BSD licensed while osmocom-bb's src/target/firmware is GPLv2(or later). Mixing GPlv2 and BSD code is legally possible. As I understand it the whole work becomes GPLv2 when the code is mixed, the BSD part however can be used independently of the GPL part if you strip out the GPL part and the BSD copyright headers have to remain intact. The problem is that upstream(nuttx) will unlikely accept GPL code as-is for inclusion in nuttx. However there is a misc directory for software made under different licenses such as applications or drivers(there is one GPL driver for the rtl8187x wifi chipsets). To use the driver the user is expected to run a script that install the driver in nuttx normal source code directory. The list of files touched by the patches mades on top of nuttx and their licenses is listed here: http://bb.osmocom.org/trac/wiki/nuttx-bb/code-audit Basically the GPL parts are composed by : * the irq * the timer * the clock * the uart some of the related files have the following authors(can be combined together): * Harald Welte * Stefan Richter * Ingo Albrecht I guess Stefan Richter and Ingo Albrecht will be hard to reach. So I wonder what's the best thing to do. Denis. From laforge at gnumonks.org Tue Feb 28 23:04:18 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 29 Feb 2012 00:04:18 +0100 Subject: [nuttx-bb] how to integrate nuttx-bb into upstream nuttx. In-Reply-To: <201202282217.37832.GNUtoo@no-log.org> References: <201202282217.37832.GNUtoo@no-log.org> Message-ID: <20120228230418.GB21122@prithivi.gnumonks.org> Hi Denis, On Tue, Feb 28, 2012 at 10:17:37PM +0100, Denis 'GNUtoo' Carikli wrote: > some of the related files have the following authors(can be combined > together): How did you do the analysis? Just by looking at the header of the file, or actually analyzing the author name information in the git commit logs of those files? The latter is probably more precise. Of course you can skip any trivial one-line changes as they are not copyrightable. > * Harald Welte As indicated before, I don't mind re-licensing under BSD-style license for the core drivers. The actual GSM protocol stack is not to be relicensed, but this is not what we're talking about anyway. > * Stefan Richter I havent' heard of im in some time, sorry. > * Ingo Albrecht He's a friend here in Berlin, and I believe he has already verbally agreed to such relicensing. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas at eversberg.eu Wed Feb 29 08:21:34 2012 From: andreas at eversberg.eu (jolly) Date: Wed, 29 Feb 2012 09:21:34 +0100 Subject: neighbour cells Message-ID: <4F4DE00E.3010509@eversberg.eu> hi, i improved the generation of neighbour cells of openbsc. the patch is committed at origin/jolly/rtpmux. it generated the system information messages of neighbour cells in the same and in other bands. depending on the location of the bcch and the neighbour cells, the messages SI 2/5 and optionally SI 2bis/5bis and SI 2ter/5ter are generated. i have tested it with several configurations. i would like to commit it to master. any suggestions? regards, andreas