From 246tnt at gmail.com  Thu Sep  1 21:26:28 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 1 Sep 2011 23:26:28 +0200
Subject: Bug in frequency list generation of libosmocore
In-Reply-To: <4e526d5b.mirider@mirider.augusta.de>
References: <4e526d5b.mirider@mirider.augusta.de>
Message-ID: <CAHL+j0_K-EJ_8Z20F4g0ADge00NMpx9iTdu7CJ4A2Jnz8z36dw@mail.gmail.com>

Hi,

Took a bit of time, but I merged it, thanks.

Cheers,

    Sylvain



From 246tnt at gmail.com  Thu Sep  1 21:30:15 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 1 Sep 2011 23:30:15 +0200
Subject: [PATCH 0/2] Adding embedded and utilities to configure options
In-Reply-To: <1313939904-27113-1-git-send-email-baseband@hackwerk.org>
References: <1313939904-27113-1-git-send-email-baseband@hackwerk.org>
Message-ID: <CAHL+j0_nA9JW2H4TWGmr_dESVEqk0oZy+2Ukc=fmSa2he=Dz9A@mail.gmail.com>

Hi Harald,

Any comments on those patches, or do they look ok to you ?

They seemed to work for me, so it's more a style issue.

The first one looks OK to me (except maybe just remove docdir
alltogether rather than comment it).
The second, it's a question of whether we leave the individual options
and just add a 'embedded one' that enables them all at once, or if we
remove all the individual ones alltogether.

Cheers,

    Sylvain

On Sun, Aug 21, 2011 at 5:18 PM, Job <baseband at hackwerk.org> wrote:
> Hi,
>
> Attached are the patches to update configure.ac and some Makefile.am to
> use more default option selection style. I commented the docdir var in
> the main Makefile.am.
>
> The second patch contains the addition of --disable-utilities and
> --enable-embedded options.
>
> I never made a patch mail before so let me know if anything is missing.
>
> Best regards,
>
> Job
>
> ====
>
> job (2):
> ?Adapted configure options to autoconf default behaviour
> ?Added autoconf option for utilities and embedded
>
> ?Makefile.am ? ? ? | ? ?2 +-
> ?configure.ac ? ? ?| ? 55 ++++++++++++++++++++++++++++++++++++++--------------
> ?utils/Makefile.am | ? ?2 +
> ?3 files changed, 43 insertions(+), 16 deletions(-)
>
> --
> 1.7.4.1
>
>
>



From laforge at gnumonks.org  Fri Sep  2 07:10:16 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 2 Sep 2011 09:10:16 +0200
Subject: [PATCH 0/2] Adding embedded and utilities to configure options
In-Reply-To: <1313939904-27113-1-git-send-email-baseband@hackwerk.org>
References: <1313939904-27113-1-git-send-email-baseband@hackwerk.org>
Message-ID: <20110902071016.GS13522@prithivi.gnumonks.org>

Hi Job,

On Sun, Aug 21, 2011 at 05:18:22PM +0200, Job wrote:

> Attached are the patches to update configure.ac and some Makefile.am to
> use more default option selection style. I commented the docdir var in
> the main Makefile.am.
> 
> The second patch contains the addition of --disable-utilities and
> --enable-embedded options.

thanks, I've just merged them.

> I never made a patch mail before so let me know if anything is missing.

everything seemed to be fine! congratulations :)

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From baseband at hackwerk.org  Fri Sep  2 19:51:51 2011
From: baseband at hackwerk.org (Job)
Date: Fri, 02 Sep 2011 21:51:51 +0200
Subject: [PATCH 0/2] Adding embedded and utilities to configure options
In-Reply-To: <20110902071016.GS13522@prithivi.gnumonks.org>
References: <1313939904-27113-1-git-send-email-baseband@hackwerk.org>
	<20110902071016.GS13522@prithivi.gnumonks.org>
Message-ID: <4E6133D7.7060503@hackwerk.org>

Hi,

>> I never made a patch mail before so let me know if anything is missing.
>
> everything seemed to be fine! congratulations :)

That's good to hear :-)

One thing to note: it still requires a patch to osmocom-bb. I did not 
provide it as I had a question on this script:

src/shared/update-libosmocore.sh

It uses "git-subtree pull" instead of "git subtree pull", which is what 
I have to use with a default install of subtree. Is it ok to change this 
in the patch for the Makefile?

Note that if you edit update-libosmocore.sh it then refuses to work 
because the source tree changed compared to the master.

Best regards,

Job





From 246tnt at gmail.com  Fri Sep  2 20:00:15 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 2 Sep 2011 22:00:15 +0200
Subject: [PATCH 0/2] Adding embedded and utilities to configure options
In-Reply-To: <4E6133D7.7060503@hackwerk.org>
References: <1313939904-27113-1-git-send-email-baseband@hackwerk.org>
	<20110902071016.GS13522@prithivi.gnumonks.org>
	<4E6133D7.7060503@hackwerk.org>
Message-ID: <CAHL+j0-nFS=hmzcuPiGrvfoQ0_r+401y4+eGTaZEogKrs04VAw@mail.gmail.com>

> One thing to note: it still requires a patch to osmocom-bb. I did not
> provide it as I had a question on this script:

Don't bother, I'm updating stuff in libosmocore right now and will
pull it into osmocom-bb and fix it myself.


Cheers,

    Sylvain



From lonelysurfer at web.de  Mon Sep 26 15:29:08 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Mon, 26 Sep 2011 08:29:08 -0700 (PDT)
Subject: where is the gprs part source in the osmocom source tree?&In-Reply
In-Reply-To: <638634.29133.qm@smtp106-mob.biz.mail.ird.yahoo.com>
References: <638634.29133.qm@smtp106-mob.biz.mail.ird.yahoo.com>
Message-ID: <1317050948019-3369559.post@n3.nabble.com>

you can get it at http://srlabs.de/gprs/

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Re-where-is-the-gprs-part-source-in-the-osmocom-source-tree-In-Reply-tp3287541p3369559.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From paul at servalproject.org  Thu Sep  1 04:11:11 2011
From: paul at servalproject.org (Paul Gardner-Stephen)
Date: Thu, 1 Sep 2011 13:41:11 +0930
Subject: 900MHz packet radio?
Message-ID: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>

Greetings all,

At the Serval Project we have created a mobile mesh telephony system
that currently works over wifi.


From spaar at mirider.augusta.de  Thu Sep  1 07:59:31 2011
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 01 Sep 2011 07:59:31 CEST
Subject: 900MHz packet radio?
Message-ID: <4e5f3b63.mirider@mirider.augusta.de>

Hello Paul,

On Thu, 1 Sep 2011 13:41:11 +0930, "Paul Gardner-Stephen" <paul at servalproject.org> wrote:
> 
> So, as the open-source group with the most experience reprogramming
> baseband radios, what is the feasibility of creating a
> proof-of-concept using the types of phones you already work with to
> send and receive arbitrary data packets without reliance on a cell
> tower (even for time synchronisation)?

It depends a lot on what you want to use on the lower layers
(e.g. Modulation). The TI Calypso based phones have a built-in
GMSK hardware modulator, so it is GMSK. Also the symbolrate is
fixed to the one used by GSM.

Then there is the DSP which does the signal processing work. Its
again tied to the GSM standard (format of the burst and length).
It might be possible to put something else into the relativ small
RAM inside the DSP, but this could be a huge effort.

Besides that you have to modify the hardware of the phone (remove
a filter) so that the phone can receive another phone. But this
is probably the smallest problem of all.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From sweisman at pobox.com  Thu Sep  1 07:18:21 2011
From: sweisman at pobox.com (Scott Weisman)
Date: Thu, 1 Sep 2011 10:18:21 +0300
Subject: 900MHz packet radio?
In-Reply-To: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
Message-ID: <CAMhwr9cUnUEQk+boxY7d7Ha3-Ymy3XSFqarESpZkS52Nw4FMKA@mail.gmail.com>

I think you would be better taking your existing hardware, which must be
somewhat custom to begin with (since it works over wifi) and use something
like a HopeRF module (http://www.hoperf.com/) or similar. HopeRF has
transceivers with power output up 100mW, data rates up to 256kbps, and a
choice of 4 different bands (315, 433, 868, 915). This sounds like it would
be a far easier choice to incorporate into your already-working system than
hacking OsmocomBB-capable phones.

There is a lot of development from many different companies in this area and
quite a bit of hacker activity as well.

Scott

On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen <paul at servalproject.org
> wrote:

> Greetings all,
>
> At the Serval Project we have created a mobile mesh telephony system
> that currently works over wifi.
>
> From the outset, we have wanted to get it working on the ISM915 and/or
> ISM868 bands that are located adjacent to the GSM 850/900 frequency
> allocations.
>
> My initial investigations and enquiries indicate that this should be
> possible by creative programming of the baseband processor in many
> models of phones.  The trick, as I suspect you well know, is the
> difficulty in getting the information and tools required to reprogram
> these radios.
>
> I am now in a position to potentially fund further work on this.
>
> So, as the open-source group with the most experience reprogramming
> baseband radios, what is the feasibility of creating a
> proof-of-concept using the types of phones you already work with to
> send and receive arbitrary data packets without reliance on a cell
> tower (even for time synchronisation)?
>
> I know there are a lot of constraints and problems, but I am most
> interested in creative solutions that can get us to a working
> prototype, however crude, that can be used to demonstrate the
> feasibility of what I am proposing.
>
> If this discussion is off-topic here, I am happy to hold the
> conversation at the serval-project-developers google group, but I am
> equally comfortable with it continuing here.
>
> Thanks in advance,
> Paul Gardner-Stephen.
> Shuttleworth Telecommunications Fellow at Flinders University.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110901/286f4d9b/attachment.htm>

From sweisman at pobox.com  Thu Sep  1 12:28:59 2011
From: sweisman at pobox.com (Scott Weisman)
Date: Thu, 1 Sep 2011 15:28:59 +0300
Subject: 900MHz packet radio?
In-Reply-To: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
Message-ID: <CAMhwr9drUU1Umad-pMH=A89W8B0KQJTgxFkzo39v=9CkFuMVbA@mail.gmail.com>

After checking out your web site, I see you're trying to use standard
off-the-shelf hardware. In that case, this is the wrong avenue to pursue. I
think a better idea, without knowing anything about the deep technical
details, would be to drop the phone-to-phone mesh network effort and focus
instead on creating some sort of BTS-in-a-box that can be deployed by
airdrop or whatever, using low power components capable of being maintained
on solar alone. The mesh networking could come into play here, where perhaps
a BTS-to-BTS mesh can be developed (again, I don't even know if this is
possible, but this seems to be a better avenue to pursue if stock cell
phones are a goal). There is at least one group working to deploy
OpenBTS-based hardware in extremely remote locations running under very
limited power budgets. This kind of solution could use 100% stock phone
hardware. While carrier-grade BTS hardware is ridiculously expensive, it
doesn't have to be that way for this kind of use case.

Also, in an emergency situation like the Haiti earthquake, which was your
inspiration, are you really going to be concerned with all the strict
legalities involved, or are you going to be more concerned with saving
lives? Let's see. Tens of thousands dead and injured, and more deaths by the
minute. So, we better make sure our hardware is 100% compliant with local
laws and difficult to deploy since it needs custom software and possible
hardware mods to function. Or, maybe, just maybe, in this type of disaster
scenario, since the local cellular service is down anyway, easily deploy a
legally questionable but 100% workable solution many times faster.

As an aside, I read an article in an amateur radio magazine back in the
1980s by someone who designed a portable solar-powered packet radio repeater
with stock hardware of the time. He use an old ammo box to hold everything
and powered it with a solar panel and motorcycle battery. It was
self-contained, had no overheating issues (he checked), and was just cool.

Scott

On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen <paul at servalproject.org
> wrote:

> Greetings all,
>
> At the Serval Project we have created a mobile mesh telephony system
> that currently works over wifi.
>
> From the outset, we have wanted to get it working on the ISM915 and/or
> ISM868 bands that are located adjacent to the GSM 850/900 frequency
> allocations.
>
> My initial investigations and enquiries indicate that this should be
> possible by creative programming of the baseband processor in many
> models of phones.  The trick, as I suspect you well know, is the
> difficulty in getting the information and tools required to reprogram
> these radios.
>
> I am now in a position to potentially fund further work on this.
>
> So, as the open-source group with the most experience reprogramming
> baseband radios, what is the feasibility of creating a
> proof-of-concept using the types of phones you already work with to
> send and receive arbitrary data packets without reliance on a cell
> tower (even for time synchronisation)?
>
> I know there are a lot of constraints and problems, but I am most
> interested in creative solutions that can get us to a working
> prototype, however crude, that can be used to demonstrate the
> feasibility of what I am proposing.
>
> If this discussion is off-topic here, I am happy to hold the
> conversation at the serval-project-developers google group, but I am
> equally comfortable with it continuing here.
>
> Thanks in advance,
> Paul Gardner-Stephen.
> Shuttleworth Telecommunications Fellow at Flinders University.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110901/0e32e529/attachment.htm>

From paul at servalproject.org  Thu Sep  1 12:47:55 2011
From: paul at servalproject.org (Paul Gardner-Stephen)
Date: Thu, 1 Sep 2011 22:17:55 +0930
Subject: 900MHz packet radio?
In-Reply-To: <CAMhwr9drUU1Umad-pMH=A89W8B0KQJTgxFkzo39v=9CkFuMVbA@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
	<CAMhwr9drUU1Umad-pMH=A89W8B0KQJTgxFkzo39v=9CkFuMVbA@mail.gmail.com>
Message-ID: <CA+_T8-CLFWkzYydu0wxbN1Fa8XADDmL2tPtriecqay_tyKvwcw@mail.gmail.com>

Hello

On Thu, Sep 1, 2011 at 9:58 PM, Scott Weisman <sweisman at pobox.com> wrote:
> After checking out your web site, I see you're trying to use standard
> off-the-shelf hardware. In that case, this is the wrong avenue to pursue. I
> think a better idea, without knowing anything about the deep technical
> details, would be to drop the phone-to-phone mesh network effort and focus
> instead on creating some sort of BTS-in-a-box that can be deployed by
> airdrop or whatever, using low power components capable of being maintained
> on solar alone. The mesh networking could come into play here, where perhaps
> a BTS-to-BTS mesh can be developed (again, I don't even know if this is
> possible, but this seems to be a better avenue to pursue if stock cell
> phones are a goal). There is at least one group working to deploy
> OpenBTS-based hardware in extremely remote locations running under very
> limited power budgets. This kind of solution could use 100% stock phone
> hardware. While carrier-grade BTS hardware is ridiculously expensive, it
> doesn't have to be that way for this kind of use case.

I hear what you are saying, and we are working to support inter-BTS
meshing for OpenBTS and OpenBSC.
However, there is also value in getting the phones to mesh, if only
because there are plenty situations where you might not be able to get
a BTS, or be able to use any BTS that is around.

> Also, in an emergency situation like the Haiti earthquake, which was your
> inspiration, are you really going to be concerned with all the strict
> legalities involved, or are you going to be more concerned with saving
> lives? Let's see. Tens of thousands dead and injured, and more deaths by the
> minute. So, we better make sure our hardware is 100% compliant with local
> laws and difficult to deploy since it needs custom software and possible
> hardware mods to function. Or, maybe, just maybe, in this type of disaster
> scenario, since the local cellular service is down anyway, easily deploy a
> legally questionable but 100% workable solution many times faster.

I know what you are saying, and much does happen in emergency
situations that is not tolerated otherwise. However this is not to say
that we should not be aspiring to fully legal solutions.
While we talk much about disaster, we also care about developing world
and rural/remote markets where incumbent cellular carriers will
certainly litigate over any unlicensed BTSes.

> As an aside, I read an article in an amateur radio magazine back in the
> 1980s by someone who designed a portable solar-powered packet radio repeater
> with stock hardware of the time. He use an old ammo box to hold everything
> and powered it with a solar panel and motorcycle battery. It was
> self-contained, had no overheating issues (he checked), and was just cool.

That is cool, and are aware that we are in many ways just re-spinning
tech that has been around 40 or 50 years, whether it be packet radio,
FIDOnet or other such technologies.

Paul.

> Scott
> On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen
> <paul at servalproject.org> wrote:
>>
>> Greetings all,
>>
>> At the Serval Project we have created a mobile mesh telephony system
>> that currently works over wifi.
>>
>> From the outset, we have wanted to get it working on the ISM915 and/or
>> ISM868 bands that are located adjacent to the GSM 850/900 frequency
>> allocations.
>>
>> My initial investigations and enquiries indicate that this should be
>> possible by creative programming of the baseband processor in many
>> models of phones. ?The trick, as I suspect you well know, is the
>> difficulty in getting the information and tools required to reprogram
>> these radios.
>>
>> I am now in a position to potentially fund further work on this.
>>
>> So, as the open-source group with the most experience reprogramming
>> baseband radios, what is the feasibility of creating a
>> proof-of-concept using the types of phones you already work with to
>> send and receive arbitrary data packets without reliance on a cell
>> tower (even for time synchronisation)?
>>
>> I know there are a lot of constraints and problems, but I am most
>> interested in creative solutions that can get us to a working
>> prototype, however crude, that can be used to demonstrate the
>> feasibility of what I am proposing.
>>
>> If this discussion is off-topic here, I am happy to hold the
>> conversation at the serval-project-developers google group, but I am
>> equally comfortable with it continuing here.
>>
>> Thanks in advance,
>> Paul Gardner-Stephen.
>> Shuttleworth Telecommunications Fellow at Flinders University.
>>
>
>



From 246tnt at gmail.com  Thu Sep  1 13:21:51 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 1 Sep 2011 15:21:51 +0200
Subject: 900MHz packet radio?
In-Reply-To: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
Message-ID: <CAHL+j092J87B2GP-Nue5dYtsPF=tAY-QFejQ48LPSwzgiOVZUw@mail.gmail.com>

You have to essentially stick with GSM mostly so:

 - Same modulation GMSK
 - Same frame structure of 4.615ms
 - Same bursts : 156.25 bits
 - Same channel coding for CCH and TCH
 - Same channel spacing of 200kHz

This way you can mostly reuse the GSM primitives offered by the baseband DSP.

Then you have to create new primitives so that phones can do between
them what they would do with a BTS
 - Transmit a FCCH / SCH ( so that a phone can become 'local master'
and provide sync to other phones )
 - RX RACH requests ( so that a phone that's 'local master' can answer
incoming requests for channels )

Both of theses actually already exist (I coded them).

Then you have to come up with a protocol that with those primitives
can build a stable mesh network.

And this latter part doesn't actually require any messing with
osmocom-bb at first, you should design and simulate it fully _first_.
And then once you have it you can start implementing it on real
hardware.

You could probably get some inspiration from the specs of TETRA DMO
mode since what you want is essentially a DMO mode for GSM.

Cheers,

    Sylvain



From paul at servalproject.org  Thu Sep  1 15:03:36 2011
From: paul at servalproject.org (Paul Gardner-Stephen)
Date: Fri, 2 Sep 2011 00:33:36 +0930
Subject: 900MHz packet radio?
In-Reply-To: <CAHL+j092J87B2GP-Nue5dYtsPF=tAY-QFejQ48LPSwzgiOVZUw@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
	<CAHL+j092J87B2GP-Nue5dYtsPF=tAY-QFejQ48LPSwzgiOVZUw@mail.gmail.com>
Message-ID: <CA+_T8-D3SAM9FtL3ShiQ04rYWJJFzb0oDdYbewbSgEWrGtM-qQ@mail.gmail.com>

Hi Sylvain,

On Thu, Sep 1, 2011 at 10:51 PM, Sylvain Munaut <246tnt at gmail.com> wrote:
> You have to essentially stick with GSM mostly so:
>
> ?- Same modulation GMSK
> ?- Same frame structure of 4.615ms
> ?- Same bursts : 156.25 bits
> ?- Same channel coding for CCH and TCH
> ?- Same channel spacing of 200kHz
>
> This way you can mostly reuse the GSM primitives offered by the baseband DSP.
>
> Then you have to create new primitives so that phones can do between
> them what they would do with a BTS
> ?- Transmit a FCCH / SCH ( so that a phone can become 'local master'
> and provide sync to other phones )
> ?- RX RACH requests ( so that a phone that's 'local master' can answer
> incoming requests for channels )
>
> Both of theses actually already exist (I coded them).

Most interesting!

> Then you have to come up with a protocol that with those primitives
> can build a stable mesh network.

Well, once there is a stable packet transport, then it is fairly easy
to build the mesh on top.

> And this latter part doesn't actually require any messing with
> osmocom-bb at first, you should design and simulate it fully _first_.
> And then once you have it you can start implementing it on real
> hardware.

Indeed. The Serval mesh software is being setup so that it can use any
link-layer, including such a GSMish one as you have described.  That
part is the easy part from my perspective.

> You could probably get some inspiration from the specs of TETRA DMO
> mode since what you want is essentially a DMO mode for GSM.

Yes, in some ways that is what we want. We also need to deal with
bridging to WiFi and some other odd bits and pieces.

Paul.

> Cheers,
>
> ? ?Sylvain
>



From 246tnt at gmail.com  Thu Sep  1 15:07:17 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 1 Sep 2011 17:07:17 +0200
Subject: 900MHz packet radio?
In-Reply-To: <CA+_T8-D3SAM9FtL3ShiQ04rYWJJFzb0oDdYbewbSgEWrGtM-qQ@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
	<CAHL+j092J87B2GP-Nue5dYtsPF=tAY-QFejQ48LPSwzgiOVZUw@mail.gmail.com>
	<CA+_T8-D3SAM9FtL3ShiQ04rYWJJFzb0oDdYbewbSgEWrGtM-qQ@mail.gmail.com>
Message-ID: <CAHL+j09aDN2GW4Y5eTvFxMD1-cxhZxYvtSxq_OvU17+dv62bYA@mail.gmail.com>

> Well, once there is a stable packet transport, then it is fairly easy
> to build the mesh on top.

You can't do it like that here (like you could with Wifi).

Because the mesh network itself is gonna have to provide negatiation
and everything _to_ establish reliable packet transport. (neighbor
discovery, master election, organization or the nodes  in 'micro
network' for sync etc etc ...).

All that needs to be figured out first, because when you power up a
phone, it doesn't have _anything_ and before it can even think about
exchanging packet, it'll have to find some other node to provide sync
... (and then whenever a node is changed / moved / ... adapt)


Cheers,

    Sylvain



From paul at servalproject.org  Thu Sep  1 15:24:37 2011
From: paul at servalproject.org (Paul Gardner-Stephen)
Date: Fri, 2 Sep 2011 00:54:37 +0930
Subject: 900MHz packet radio?
In-Reply-To: <CAHL+j09aDN2GW4Y5eTvFxMD1-cxhZxYvtSxq_OvU17+dv62bYA@mail.gmail.com>
References: <CA+_T8-Cu076ZMxabb-8D13uw8jM4EuAscAuqVkfPzm9tFo+QuA@mail.gmail.com>
	<CAHL+j092J87B2GP-Nue5dYtsPF=tAY-QFejQ48LPSwzgiOVZUw@mail.gmail.com>
	<CA+_T8-D3SAM9FtL3ShiQ04rYWJJFzb0oDdYbewbSgEWrGtM-qQ@mail.gmail.com>
	<CAHL+j09aDN2GW4Y5eTvFxMD1-cxhZxYvtSxq_OvU17+dv62bYA@mail.gmail.com>
Message-ID: <CA+_T8-CU=ynEHhXXtA-LHEmXkLHTdcFbAQCt7P6tpXS9z3YFHw@mail.gmail.com>

Hello,

On Fri, Sep 2, 2011 at 12:37 AM, Sylvain Munaut <246tnt at gmail.com> wrote:
>> Well, once there is a stable packet transport, then it is fairly easy
>> to build the mesh on top.
>
> You can't do it like that here (like you could with Wifi).
>
> Because the mesh network itself is gonna have to provide negatiation
> and everything _to_ establish reliable packet transport. (neighbor
> discovery, master election, organization or the nodes ?in 'micro
> network' for sync etc etc ...).
>
> All that needs to be figured out first, because when you power up a
> phone, it doesn't have _anything_ and before it can even think about
> exchanging packet, it'll have to find some other node to provide sync
> ... (and then whenever a node is changed / moved / ... adapt)

Gotcha. I mis-interpreted your previous message as you had built an
election system from your primitives.

Okay, so time to start thinking about how to bootstrap the process.
Simplest approach that comes to mind would be for every phone to
listen for a master, and if it can't hear one, try to be one. Then
have a resolution process for when multiple masters are present.

In any case, very interested to take a look at your primitives and how
they might be assembled to meet our needs.

Paul.

>
> Cheers,
>
> ? ?Sylvain
>



From mad at auth.se  Thu Sep  1 16:40:10 2011
From: mad at auth.se (mad)
Date: Thu, 01 Sep 2011 18:40:10 +0200
Subject: =?iso-8859-1?Q?Re=3A_900MHz_packet_radio=3F?=
In-Reply-To: <CA+_T8-CU=ynEHhXXtA-LHEmXkLHTdcFbAQCt7P6tpXS9z3YFHw@mail.gmail.com>
Message-ID: <20110901164010.61e58ea7@mail.auth.se>

Hi Paul,

another point to assess is if it is feasible at all to use these devices with a to-be-developed p2p protocol in terms of practicability to operate them in the field as you intend.

Because there is still the issue of power consumption you can not get around so easily.
GSM phones can maintain their high standby-times only by relying on stable basestations to be able to switch off their transceivers for most of the time.

As Sylvain stated there has to be a master kind of imitating the BS for its neighbours to sync on. This master most certainly had to send a beacon all the time so its battery would drain quickly. The operation time in master mode would be significantly less than the usual speech-time of that phone, so not much more than very few hours.

As there is only a short radio range, all participating devices had to act as a master for some time of their operation and suffer from this energy consuming mode, especially in loosely covered areas where are no or few other devices reachable.

It's just my view that this should be considered, too, before making huge efforts to implement sth. like this for the intended purpose.
Of course it would be a cool addon to osmocom-bb and this shouldn't keep anybody from doing this for the sake of rising to the challenge. ;-)


Regards,
  Mad



From paul at servalproject.org  Thu Sep  1 21:16:11 2011
From: paul at servalproject.org (Paul Gardner-Stephen)
Date: Fri, 2 Sep 2011 06:46:11 +0930
Subject: 900MHz packet radio?
In-Reply-To: <20110901164010.61e58ea7@mail.auth.se>
References: <CA+_T8-CU=ynEHhXXtA-LHEmXkLHTdcFbAQCt7P6tpXS9z3YFHw@mail.gmail.com>
	<20110901164010.61e58ea7@mail.auth.se>
Message-ID: <CA+_T8-D_T-tom8HBsQ+4CVVRrhckzWyf4p7KhcvgR2rU=G+12Q@mail.gmail.com>

Hello Mad,

On Fri, Sep 2, 2011 at 2:10 AM, mad <mad at auth.se> wrote:
> Hi Paul,
>
> another point to assess is if it is feasible at all to use these devices with a to-be-developed p2p protocol in terms of practicability to operate them in the field as you intend.
>
> Because there is still the issue of power consumption you can not get around so easily.
> GSM phones can maintain their high standby-times only by relying on stable basestations to be able to switch off their transceivers for most of the time.
>
> As Sylvain stated there has to be a master kind of imitating the BS for its neighbours to sync on. This master most certainly had to send a beacon all the time so its battery would drain quickly. The operation time in master mode would be significantly less than the usual speech-time of that phone, so not much more than very few hours.
>
> As there is only a short radio range, all participating devices had to act as a master for some time of their operation and suffer from this energy consuming mode, especially in loosely covered areas where are no or few other devices reachable.
>
> It's just my view that this should be considered, too, before making huge efforts to implement sth. like this for the intended purpose.

You're absolutely right about energy consumption. In fact, this is a
big problem for WiFi too, as there it is difficult to disable the 10Hz
beaconing in ad-hoc mode.

Our view is that the right technology for other occasions, e.g.,, GSM,
exists, but we want to at least provide the possibility of
communications in the other situations, which it turns out happens
fairly often (disaster, remote, developing countries).

We will also look into tricks like using the beacons from a nearby
cell to synchronise ourselves if it is available, as that should
enable us to save a lot of power, and only resort to beaconing
ourselves if we really have to.

Your point about sharing around the being master is an important
point, and certainly one that would need to implement.

> Of course it would be a cool addon to osmocom-bb and this shouldn't keep anybody from doing this for the sake of rising to the challenge. ;-)

Well, if it looked like it was sensible, then someone else would
probably have done it ;)
Anyway, I am committed to at least try, and intend to throw some
resources (including financial) behind the effort.
Besides, the more this conversation continues, the more convinced I am
that it is possible, even if the solution might be a conglomeration of
rather interesting work-arounds.

The point is that there is every possibility that it will work, and if
it does, then one of the eventual side-effects should be the gaining
of access to material that will enable the reprogramming of more
modern baseband processors to positive ends, which will be much more
interesting for everyone.

Paul.

>
> Regards,
> ?Mad
>



From paul at servalproject.org  Thu Sep  1 12:30:34 2011
From: paul at servalproject.org (Paul Gardner-Stephen)
Date: Thu, 1 Sep 2011 22:00:34 +0930
Subject: baseband-devel Digest, Vol 20, Issue 1
In-Reply-To: <mailman.4.1314871202.22622.baseband-devel@lists.osmocom.org>
References: <mailman.4.1314871202.22622.baseband-devel@lists.osmocom.org>
Message-ID: <CA+_T8-BZc9YaUjjjF-9sz=yyxapPNTMYZjfAYfVyzGAFeN_GLg@mail.gmail.com>

On Thu, Sep 1, 2011 at 7:30 PM,
<baseband-devel-request at lists.osmocom.org> wrote:
Hello,

Thank you Dieter and Scott for your fast responses.

> ---------- Forwarded message ----------
> From:?"Dieter Spaar" <spaar at mirider.augusta.de>
> To:?baseband-devel at lists.osmocom.org
> Date:?Thu, 01 Sep 2011 07:59:31 CEST
> Subject:?Re: 900MHz packet radio?
> Hello Paul,
>
> On Thu, 1 Sep 2011 13:41:11 +0930, "Paul Gardner-Stephen" <paul at servalproject.org> wrote:
>>
>> So, as the open-source group with the most experience reprogramming
>> baseband radios, what is the feasibility of creating a
>> proof-of-concept using the types of phones you already work with to
>> send and receive arbitrary data packets without reliance on a cell
>> tower (even for time synchronisation)?
>
> It depends a lot on what you want to use on the lower layers
> (e.g. Modulation). The TI Calypso based phones have a built-in
> GMSK hardware modulator, so it is GMSK. Also the symbolrate is
> fixed to the one used by GSM.

I had assumed that the modulation would be fixed in this way, and it
is not an issue for what I am wanting to do. In fact, it makes a lot
of sense to keep the GSM modulation for simplicity.

> Then there is the DSP which does the signal processing work. Its
> again tied to the GSM standard (format of the burst and length).
> It might be possible to put something else into the relativ small
> RAM inside the DSP, but this could be a huge effort.

This seems to me to be the hardest part of the whole process.
When you say a huge effort, do you think it would be possible for
someone to be able to get something working if they were able to work
on it full-time for a few months?

> Besides that you have to modify the hardware of the phone (remove
> a filter) so that the phone can receive another phone. But this
> is probably the smallest problem of all.

Indeed, this is the smallest problem I think.  In fact, if we use the
part of the ISM915 band that is right next to the GSM band, then my
understanding is the filter will only attenuate by a few db --
although I am happy to be corrected on this point.

> Best regards,
> ?Dieter
> --
> Dieter Spaar, Germany ? ? ? ? ? ? ? ? ? ? ? ? ? spaar at mirider.augusta.de
>
>
>
>
> ---------- Forwarded message ----------
> From:?Scott Weisman <sweisman at pobox.com>
> To:?baseband-devel <baseband-devel at lists.osmocom.org>
> Date:?Thu, 1 Sep 2011 10:18:21 +0300
> Subject:?Re: 900MHz packet radio?
> I think you would be better taking your existing hardware, which must be somewhat custom to begin with (since it works over wifi) and use something like a HopeRF module (http://www.hoperf.com/) or similar. HopeRF has transceivers with power output up 100mW, data rates up to 256kbps, and a choice of 4 different bands (315, 433, 868, 915). This sounds like it would be a far easier choice to incorporate into your already-working system than hacking OsmocomBB-capable phones.
> There is a lot of development from many different companies in this area and quite a bit of hacker activity as well.

We are exploring that path simultaneously, and have a batch of the
exactly the HopeRF modules that we will use, to demonstrate the range
and utility of using the ISM band for long-range mesh telephony.

But it is important also that we prove that it can be done using the
baseband radio in a phone.

We all know that it can if we have the freedom to design the baseband
radio from scratch, but that it can also be done it is also important
that I show that for handsets where the baseband radio can be
reprogrammed without changing the hardware.

It all boils down to being able to deflect any straw arguments that
might be raised against the feasibility of long-range mesh telephony
using baseband radio.

Paul.

> Scott
>
> On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen <paul at servalproject.org> wrote:
>>
>> Greetings all,
>>
>> At the Serval Project we have created a mobile mesh telephony system
>> that currently works over wifi.
>>
>> >From the outset, we have wanted to get it working on the ISM915 and/or
>> ISM868 bands that are located adjacent to the GSM 850/900 frequency
>> allocations.
>>
>> My initial investigations and enquiries indicate that this should be
>> possible by creative programming of the baseband processor in many
>> models of phones. ?The trick, as I suspect you well know, is the
>> difficulty in getting the information and tools required to reprogram
>> these radios.
>>
>> I am now in a position to potentially fund further work on this.
>>
>> So, as the open-source group with the most experience reprogramming
>> baseband radios, what is the feasibility of creating a
>> proof-of-concept using the types of phones you already work with to
>> send and receive arbitrary data packets without reliance on a cell
>> tower (even for time synchronisation)?
>>
>> I know there are a lot of constraints and problems, but I am most
>> interested in creative solutions that can get us to a working
>> prototype, however crude, that can be used to demonstrate the
>> feasibility of what I am proposing.
>>
>> If this discussion is off-topic here, I am happy to hold the
>> conversation at the serval-project-developers google group, but I am
>> equally comfortable with it continuing here.
>>
>> Thanks in advance,
>> Paul Gardner-Stephen.
>> Shuttleworth Telecommunications Fellow at Flinders University.
>>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>



From eng_basemm at yahoo.com  Sat Sep  3 07:23:05 2011
From: eng_basemm at yahoo.com (Basem Ahmed)
Date: Sat, 3 Sep 2011 00:23:05 -0700 (PDT)
Subject: Motorola C119 
Message-ID: <1315034585.85533.YahooMailNeo@web125920.mail.ne1.yahoo.com>




Hi All,

I got new Motorola phone modeled "C119" Its shape like feature Motorola C118 but i tried to programmed with OSMOCON utility with the loader or with the simtest applications but it did not work ,So any help please ?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110903/1eafadb3/attachment.htm>

From alexander.huemer at xx.vu  Sat Sep  3 08:24:19 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Sat, 3 Sep 2011 10:24:19 +0200
Subject: Motorola C119
In-Reply-To: <1315034585.85533.YahooMailNeo@web125920.mail.ne1.yahoo.com>
References: <1315034585.85533.YahooMailNeo@web125920.mail.ne1.yahoo.com>
Message-ID: <20110903082419.GA11992@de.xx.vu>

Ahmed,

> it did not work
unfortunately has very little descriptive value.
Without knowing what happens nobody here can help you.
Start with pasting the error messages you get in an email (monospace
font, preferably text-only email) and by telling the ML which cable you
use.

Kind regards
-Alexander Huemer




From eng_basemm at yahoo.com  Sun Sep  4 09:51:32 2011
From: eng_basemm at yahoo.com (Basem Ahmed)
Date: Sun, 4 Sep 2011 02:51:32 -0700 (PDT)
Subject: Motorola C119
In-Reply-To: <20110903082419.GA11992@de.xx.vu>
References: <1315034585.85533.YahooMailNeo@web125920.mail.ne1.yahoo.com>
	<20110903082419.GA11992@de.xx.vu>
Message-ID: <1315129892.37937.YahooMailNeo@web125907.mail.ne1.yahoo.com>

Hi All,

When i tried C119 with T191 Cable with the following configuration ?(Anything except?c140xor and?compal_e86): it did not give complete response with Acknowledging from the phone with response like this:

linux-d5zo:/home/basem/osmocom-bb/src/host/osmocon # ./osmocon -p /dev/ttyUSB0 -m c115 ../../target/firmware/board/compal_e88/layer1.compalram.bin?
got 2 bytes from modem, data looks like: 04 81 ?..
got 5 bytes from modem, data looks like: 1b f6 02 00 41 ?....A
got 1 bytes from modem, data looks like: 01 ?.
got 1 bytes from modem, data looks like: 40 ?@
Received PROMPT1 from phone, responding with CMD

The filesize is larger than 15kb, code on the magic address will be overwritten!
Use loader.bin and upload the application with osmoload instead!

read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin): file_size=54104, hdr_len=4, dnload_len=54111
got 1 bytes from modem, data looks like: 1b ?.
got 1 bytes from modem, data looks like: f6 ?.
got 1 bytes from modem, data looks like: 02 ?.
got 1 bytes from modem, data looks like: 00 ?.
got 1 bytes from modem, data looks like: 41 ?A
got 1 bytes from modem, data looks like: 02 ?.
got 1 bytes from modem, data looks like: 43 ?C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/54111)
handle_write(): 4096 bytes (8192/54111)
handle_write(): 4096 bytes (12288/54111)
handle_write(): 4096 bytes (16384/54111)
handle_write(): 4096 bytes (20480/54111)
handle_write(): 4096 bytes (24576/54111)
handle_write(): 4096 bytes (28672/54111)
handle_write(): 4096 bytes (32768/54111)
handle_write(): 4096 bytes (36864/54111)
handle_write(): 4096 bytes (40960/54111)
handle_write(): 4096 bytes (45056/54111)
handle_write(): 4096 bytes (49152/54111)
handle_write(): 4096 bytes (53248/54111)
handle_write(): 863 bytes (54111/54111)
handle_write(): finished

But when i tried with " C140XOR and Compal_e86 " it gives me the complete response but only two errors which is the LCD writing is shifted up by one line and the phone did not registered to the network here is the following response :

  Why "show ms 1" is saying:

OsmocomBB#?show?ms 1
MS?'1'?is?up,?MM?connection?active
??IMEI:?000000000000000
?????IMEISV:?0000000000000000
?????IMEI?generation:?fixed
??automatic?network?selection?state:?A1?trying?RPLMN
??cell?selection?state:?C3?camped?normally
??radio?ressource?layer?state:?connection?pending
??mobility?management?layer?state:?wait?for?RR?connection?(location?updating)

?and in the mobile application gives the following :
 linux-d5zo:/home/basem/osmocom-bb/src/host/osmocon # ./osmocon -p /dev/ttyUSB0 -m c140xor ../../target/firmware/board/compal_e88/layer1.compalram.bin?
got 2 bytes from modem, data looks like: 04 81 ?..
got 5 bytes from modem, data looks like: 1b f6 02 00 41 ?....A
got 1 bytes from modem, data looks like: 01 ?.
got 1 bytes from modem, data looks like: 40 ?@
Received PROMPT1 from phone, responding with CMD

The filesize is larger than 15kb, code on the magic address will be overwritten!
Use loader.bin and upload the application with osmoload instead!

read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin): file_size=54104, hdr_len=4, dnload_len=54111
got 1 bytes from modem, data looks like: 1b ?.
got 1 bytes from modem, data looks like: f6 ?.
got 1 bytes from modem, data looks like: 02 ?.
got 1 bytes from modem, data looks like: 00 ?.
got 1 bytes from modem, data looks like: 41 ?A
got 1 bytes from modem, data looks like: 02 ?.
got 1 bytes from modem, data looks like: 43 ?C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/54111)
handle_write(): 4096 bytes (8192/54111)
handle_write(): 4096 bytes (12288/54111)
handle_write(): 4096 bytes (16384/54111)
handle_write(): 4096 bytes (20480/54111)
handle_write(): 4096 bytes (24576/54111)
handle_write(): 4096 bytes (28672/54111)
handle_write(): 4096 bytes (32768/54111)
handle_write(): 4096 bytes (36864/54111)
handle_write(): 4096 bytes (40960/54111)
handle_write(): 4096 bytes (45056/54111)
handle_write(): 4096 bytes (49152/54111)
handle_write(): 4096 bytes (53248/54111)
handle_write(): 863 bytes (54111/54111)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b ?.
got 1 bytes from modem, data looks like: f6 ?.
got 1 bytes from modem, data looks like: 02 ?.
got 1 bytes from modem, data looks like: 00 ?.
got 1 bytes from modem, data looks like: 41 ?A
got 1 bytes from modem, data looks like: 03 ?.
got 1 bytes from modem, data looks like: 42 ?B
Received DOWNLOAD ACK from phone, your code is running now!


OSMOCOM Layer 1 (revision osmocon_v0.0.0-906-g5589a6b-modified)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e144263d880014fd
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
Power up simcard:
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 1203!
SIM Request (7): a0 a4 00 00 02 3f 00?
Status 2: 9F 23
SIM Request (5): a0 c0 00 00 23?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 2f e2?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 0a?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 7f 20?
Status 2: 9F 23
SIM Request (5): a0 c0 00 00 23?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 07?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 09?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 7e?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 0b?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 3f 00?
Status 2: 9F 23
SIM Request (5): a0 c0 00 00 23?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 7f 10?
Status 2: 9F 23
SIM Request (5): a0 c0 00 00 23?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 40?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 84?
Status 1: 94 08
SIM Request (7): a0 a4 00 00 02 3f 00?
Status 2: 9F 23
SIM Request (5): a0 c0 00 00 23?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 7f 20?
Status 2: 9F 23
SIM Request (5): a0 c0 00 00 23?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 20?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 09?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 30?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 3c?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 31?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 01?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 46?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 11?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 78?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 02?
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 7b?
Status 2: 9F 13
SIM Request (5): a0 c0 00 00 13?
Status 1: 90 00
SIM Request (5): a0 b0 00 00 0c?
Status 1: 90 00
L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=100 end=104
PM MEAS: ARFCN=100, 28 ? dBm at baseband, -109 dBm at RF
PM MEAS: ARFCN=100, 30 ? dBm at baseband, -107 dBm at RF
PM MEAS: ARFCN=101, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=102, 26 ? dBm at baseband, -112 dBm at RF
PM MEAS: ARFCN=103, 34 ? dBm at baseband, -104 dBm at RF
PM MEAS: ARFCN=104, 25 ? dBm at baseband, -112 dBm at RF
L1CTL_PM_REQ start=106 end=106
PM MEAS: ARFCN=106, 26 ? dBm at baseband, -111 dBm at RF
PM MEAS: ARFCN=106, 25 ? dBm at baseband, -112 dBm at RF
L1CTL_PM_REQ start=108 end=110
PM MEAS: ARFCN=108, 31 ? dBm at baseband, -106 dBm at RF
PM MEAS: ARFCN=108, 30 ? dBm at baseband, -107 dBm at RF
PM MEAS: ARFCN=109, 25 ? dBm at baseband, -112 dBm at RF
PM MEAS: ARFCN=110, 24 ? dBm at baseband, -113 dBm at RF
L1CTL_PM_REQ start=112 end=121
PM MEAS: ARFCN=112, 28 ? dBm at baseband, -109 dBm at RF
PM MEAS: ARFCN=112, 27 ? dBm at baseband, -110 dBm at RF
PM MEAS: ARFCN=113, 32 ? dBm at baseband, -105 dBm at RF
PM MEAS: ARFCN=114, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=115, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=116, 30 ? dBm at baseband, -107 dBm at RF
PM MEAS: ARFCN=117, 31 ? dBm at baseband, -106 dBm at RF
PM MEAS: ARFCN=118, 33 ? dBm at baseband, -104 dBm at RF
PM MEAS: ARFCN=119, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=120, 45 ? dBm at baseband, -92 ?dBm at RF
PM MEAS: ARFCN=121, 65 ? dBm at baseband, -72 ?dBm at RF
L1CTL_PM_REQ start=124 end=124
PM MEAS: ARFCN=124, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=124, 29 ? dBm at baseband, -108 dBm at RF
L1CTL_PM_REQ start=762 end=762
PM MEAS: ARFCN=762, 84 ? dBm at baseband, -54 ?dBm at RF
PM MEAS: ARFCN=762, 84 ? dBm at baseband, -53 ?dBm at RF
L1CTL_PM_REQ start=765 end=768
PM MEAS: ARFCN=765, 41 ? dBm at baseband, -96 ?dBm at RF
PM MEAS: ARFCN=765, 42 ? dBm at baseband, -95 ?dBm at RF
PM MEAS: ARFCN=766, 38 ? dBm at baseband, -99 ?dBm at RF
PM MEAS: ARFCN=767, 57 ? dBm at baseband, -80 ?dBm at RF
PM MEAS: ARFCN=768, 46 ? dBm at baseband, -91 ?dBm at RF
L1CTL_PM_REQ start=773 end=773
PM MEAS: ARFCN=773, 33 ? dBm at baseband, -105 dBm at RF
PM MEAS: ARFCN=773, 32 ? dBm at baseband, -105 dBm at RF
L1CTL_PM_REQ start=775 end=776
PM MEAS: ARFCN=775, 48 ? dBm at baseband, -89 ?dBm at RF
PM MEAS: ARFCN=775, 48 ? dBm at baseband, -89 ?dBm at RF
PM MEAS: ARFCN=776, 41 ? dBm at baseband, -96 ?dBm at RF
L1CTL_PM_REQ start=779 end=779
PM MEAS: ARFCN=779, 51 ? dBm at baseband, -86 ?dBm at RF
PM MEAS: ARFCN=779, 52 ? dBm at baseband, -85 ?dBm at RF
L1CTL_PM_REQ start=797 end=797
PM MEAS: ARFCN=797, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=797, 29 ? dBm at baseband, -108 dBm at RF
L1CTL_PM_REQ start=816 end=816
PM MEAS: ARFCN=816, 29 ? dBm at baseband, -108 dBm at RF
PM MEAS: ARFCN=816, 28 ? dBm at baseband, -109 dBm at RF
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=762, flags=0x7)
Starting FCCH RecognitionFB0 (1419:2): TOA= 1968, Power= -54dBm, Angle= 6913Hz
FB1 (1429:8): TOA= 9431, Power= -53dBm, Angle= ?858Hz
? fn_offset=1428 (fn=1429 + attempt=8 + ntdma = 7)m ?delay=9 (fn_offset=1428 + 11 - fn=1429 - 1
? scheduling next FB/SB detection task with delay 9
FB1 (1440:1): TOA= ?683, Power= -53dBm, Angle= ?165Hz
? fn_offset=1439 (fn=1440 + attempt=1 + ntdma = 0)m ?delay=9 (fn_offset=1439 + 11 - fn=1440 - 1
? scheduling next FB/SB detection task with delay 9
=>FB @ FNR 1439 fn_offset=1439 qbits=2548
Synchronize_TDMA
LOST 2859!
SB1 (2891:1): TOA= ? 23, Power= -53dBm, Angle= ?135Hz
=> SB 0x01e4ab7f: BSIC=31 fn=2492177(1879/25/11) qbits=0
Synchronize_TDMA
=>FB @ FNR 2890 fn_offset=2492177 qbits=4908
LOST 1903!
L1CTL_RESET_REQ: FULL!EMPTY
L1CTL_FBSB_REQ (arfcn=762, flags=0x7)
Starting FCCH RecognitionFB0 (2492554:3): TOA= 2544, Power= -54dBm, Angle= 6840Hz
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=762, flags=0x7)
Starting FCCH RecognitionFB0 (2492575:9): TOA= 9312, Power= -54dBm, Angle= 6777Hz
FB1 (2492585:8): TOA= 8755, Power= -53dBm, Angle= 1051Hz
? fn_offset=2492583 (fn=2492585 + attempt=8 + ntdma = 6)m ?delay=8 (fn_offset=2492583 + 11 - fn=2492585 - 1
? scheduling next FB/SB detection task with delay 8
FB1 (2492605:11): TOA=12503, Power= -53dBm, Angle= ?160Hz
? fn_offset=2492603 (fn=2492605 + attempt=11 + ntdma = 9)m ?delay=8 (fn_offset=2492603 + 11 - fn=2492605 - 1
? scheduling next FB/SB detection task with delay 8
=> DSP reports FB in bit that is 1179237253 bits in the future?!?
Synchronize_TDMA
LOST 3714!
SB1 (2269562:1): TOA= ? 29, Power= -53dBm, Angle= ? ?9Hz
=> SB 0x00d6ab7f: BSIC=31 fn=2492615(1879/21/41)=> DSP reports SB in bit that is 1458016052 bits in the future?!?
Synchronize_TDMA
=> DSP reports FB in bit that is 1458016029 bits in the future?!?
LOST 1912!

Thanks
  

________________________________
From: Alexander Huemer <alexander.huemer at xx.vu>
To: Basem Ahmed <eng_basemm at yahoo.com>
Cc: "baseband-devel at lists.osmocom.org" <baseband-devel at lists.osmocom.org>
Sent: Saturday, September 3, 2011 11:24 AM
Subject: Re: Motorola C119

Ahmed,

> it did not work
unfortunately has very little descriptive value.
Without knowing what happens nobody here can help you.
Start with pasting the error messages you get in an email (monospace
font, preferably text-only email) and by telling the ML which cable you
use.

Kind regards
-Alexander Huemer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110904/b8665c70/attachment.htm>

From steve at steve-m.de  Sun Sep  4 11:08:15 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 04 Sep 2011 13:08:15 +0200
Subject: Motorola C119
In-Reply-To: <1315129892.37937.YahooMailNeo@web125907.mail.ne1.yahoo.com>
References: <1315034585.85533.YahooMailNeo@web125920.mail.ne1.yahoo.com>
	<20110903082419.GA11992@de.xx.vu>
	<1315129892.37937.YahooMailNeo@web125907.mail.ne1.yahoo.com>
Message-ID: <4E635C1F.5070903@steve-m.de>

Hi,

On 04.09.2011 11:51, Basem Ahmed wrote:

> linux-d5zo:/home/basem/osmocom-bb/src/host/osmocon # ./osmocon -p
> /dev/ttyUSB0 -m c140xor

> The filesize is larger than 15kb, code on the magic address will be
> overwritten!
> Use loader.bin and upload the application with osmoload instead!

You need to chainload the application, see:
http://bb.osmocom.org/trac/wiki/MotorolaC140#Bootloader

So when using xor, the command would be:

./osmocon -p /dev/ttyUSB0 -m c140xor -c
../../target/firmware/board/compal_e86/layer1.highram.bin
../../target/firmware/board/compal_e86/chainload.compalram.bin

Regards,
Steve



From baseband at hackwerk.org  Sat Sep  3 09:42:25 2011
From: baseband at hackwerk.org (Job)
Date: Sat, 03 Sep 2011 11:42:25 +0200
Subject: serial issues on fast PC
Message-ID: <4E61F681.4060909@hackwerk.org>

Hi,

While testing on a new PC I ran into the following issue.

Same phone (C115), same USB cable FTDI RS232 + RS232 -> 3v3, works on a
slow Atom PC with latest osmocom-bb git, but fails with fmtool error on
a fast i7 core PC.

The fail happens after sending the first 4096 bytes with a NACK from the
phone. Once in many tries it actually does download something but then
fails to run the image.

Has anyone seen such behaviour? Any ideas on what might go wrong?

If not I'll spend some time to debug it.

Best regards,

Job



From 246tnt at gmail.com  Sat Sep  3 09:51:39 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 3 Sep 2011 11:51:39 +0200
Subject: serial issues on fast PC
In-Reply-To: <4E61F681.4060909@hackwerk.org>
References: <4E61F681.4060909@hackwerk.org>
Message-ID: <CAHL+j0-31si+-Ue_O_P3naKZZFmg--E-33TFFe-w23zK=j0PeQ@mail.gmail.com>

Hi,

> Has anyone seen such behaviour? Any ideas on what might go wrong?

Did you try both -m c123 and -m c123xor ?

Cheers,

    Sylvain



From baseband at hackwerk.org  Sat Sep  3 11:07:32 2011
From: baseband at hackwerk.org (Job)
Date: Sat, 03 Sep 2011 13:07:32 +0200
Subject: serial issues on fast PC
In-Reply-To: <CAHL+j0-31si+-Ue_O_P3naKZZFmg--E-33TFFe-w23zK=j0PeQ@mail.gmail.com>
References: <4E61F681.4060909@hackwerk.org>
	<CAHL+j0-31si+-Ue_O_P3naKZZFmg--E-33TFFe-w23zK=j0PeQ@mail.gmail.com>
Message-ID: <4E620A74.7050805@hackwerk.org>

Hi,

>> Has anyone seen such behaviour? Any ideas on what might go wrong?
> 
> Did you try both -m c123 and -m c123xor ?

Thanks! It worked, but I do not fully understand why.

So on the Atom it works with c123xor, but with c123 it starts
downloading until about 65% and then fails.

On the i7 the c123xor fails, but the c123 works fine.

All the same equipment and software, OS etc. Except for the PC.

What is the explanation?

Thanks,

Job




From alexander.chemeris at gmail.com  Mon Sep  5 19:32:53 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 5 Sep 2011 23:32:53 +0400
Subject: Osmocom + USRP
Message-ID: <CABmJbFXaPEcdXKNiydkCqPggKkrYU0n0x-xSoi5J=YEcMR_BNg@mail.gmail.com>

Hi Harald and all,

I have a client who is interested in an USRP-based MS side implementation. I
think that that OsmocomBB is a natural choice for the higher-level stack,
but I have only vague idea about its current state. As I understand, burst
coding/modulation, reference clock management and GSM clock management
should be implemented to get a working MS. Is there anything else to
implement? How well is API to Calypso DSP is abstracted in OsmocomBB?

(Sorry for my brevity and no googling, I'm abroad on GPRS for few weeks)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110905/b8369e38/attachment.htm>

From laforge at gnumonks.org  Thu Sep  8 06:56:56 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 8 Sep 2011 08:56:56 +0200
Subject: Osmocom + USRP
In-Reply-To: <CABmJbFXaPEcdXKNiydkCqPggKkrYU0n0x-xSoi5J=YEcMR_BNg@mail.gmail.com>
References: <CABmJbFXaPEcdXKNiydkCqPggKkrYU0n0x-xSoi5J=YEcMR_BNg@mail.gmail.com>
Message-ID: <20110908065656.GC30888@prithivi.gnumonks.org>

Hi Alexander,

On Mon, Sep 05, 2011 at 11:32:53PM +0400, Alexander Chemeris wrote:

> I have a client who is interested in an USRP-based MS side implementation. I
> think that that OsmocomBB is a natural choice for the higher-level stack,
> but I have only vague idea about its current state. 

It's fairly complete, you can do FR/EFR/HR voice calls (AMR still
missing), it does cell (re)selection, encryption, hand-over, etc.

What's mostly missing is SMS support.

> As I understand, burst coding/modulation, reference clock management
> and GSM clock management should be implemented to get a working MS. Is
> there anything else to implement? How well is API to Calypso DSP is
> abstracted in OsmocomBB?

The actual layer1 firmware (on the calypso ARM side) is probably very
calyps specific, as it uses its various hardware components.
Nonetheless, there may be things like the TDMA scheduler and multiframe
scheduler which may make sense in different environments, too.

The entire L1 is abstracted from L2 using an interface called L1CTL.

This interface is specified as a protocol, and we normally speak it over
RS232 to the calypso phone.  It is defined in l1ctl_proto.h

As the calypso is the only hardware we support so far, there may be some
leakage into L1CTL, i.e. some things might not be perfect for other L1
implementations.  But we're happy to make changes to it.

Please note: there are two alternative solutions
 * kestrel/range have a proprietary product calledo OpenMS based on
   OpenBTS.  It's not Open Source, though.
 * The L1 of the upcoming sysmoBTS already has limited support for
   behaving like a MS.  It's not a primary feature, as we think it's
   just too expensive compared to a cheap calypso phone.  However, the
   L1 interface is definitely better defined as L1CTL.

I think Andreas Eversberg, Dieter Spaar or Sylvain Munaut would be good
candidates to take care of the implementation, in case you're looking
for somebody to take on that project.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From alexander.chemeris at gmail.com  Thu Sep  8 07:50:47 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 8 Sep 2011 11:50:47 +0400
Subject: Osmocom + USRP
In-Reply-To: <20110908065656.GC30888@prithivi.gnumonks.org>
References: <CABmJbFXaPEcdXKNiydkCqPggKkrYU0n0x-xSoi5J=YEcMR_BNg@mail.gmail.com>
	<20110908065656.GC30888@prithivi.gnumonks.org>
Message-ID: <CABmJbFUf1OEJr9+94fMCvfsDzNAG3YOCc2OtCm36hz5Z0MD+6g@mail.gmail.com>

Hi Harald,

Thank you very much for the detailed description. I'll talk with my
customer and see whether they really want what they're asking for. I
proposed them to use OsmocomBB with Calypso, but their initial
response was "no-no, we want USRP".

On Thu, Sep 8, 2011 at 10:56, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Alexander,
>
> On Mon, Sep 05, 2011 at 11:32:53PM +0400, Alexander Chemeris wrote:
>
>> I have a client who is interested in an USRP-based MS side implementation. I
>> think that that OsmocomBB is a natural choice for the higher-level stack,
>> but I have only vague idea about its current state.
>
> It's fairly complete, you can do FR/EFR/HR voice calls (AMR still
> missing), it does cell (re)selection, encryption, hand-over, etc.
>
> What's mostly missing is SMS support.
>
>> As I understand, burst coding/modulation, reference clock management
>> and GSM clock management should be implemented to get a working MS. Is
>> there anything else to implement? How well is API to Calypso DSP is
>> abstracted in OsmocomBB?
>
> The actual layer1 firmware (on the calypso ARM side) is probably very
> calyps specific, as it uses its various hardware components.
> Nonetheless, there may be things like the TDMA scheduler and multiframe
> scheduler which may make sense in different environments, too.
>
> The entire L1 is abstracted from L2 using an interface called L1CTL.
>
> This interface is specified as a protocol, and we normally speak it over
> RS232 to the calypso phone. ?It is defined in l1ctl_proto.h
>
> As the calypso is the only hardware we support so far, there may be some
> leakage into L1CTL, i.e. some things might not be perfect for other L1
> implementations. ?But we're happy to make changes to it.
>
> Please note: there are two alternative solutions
> ?* kestrel/range have a proprietary product calledo OpenMS based on
> ? OpenBTS. ?It's not Open Source, though.
> ?* The L1 of the upcoming sysmoBTS already has limited support for
> ? behaving like a MS. ?It's not a primary feature, as we think it's
> ? just too expensive compared to a cheap calypso phone. ?However, the
> ? L1 interface is definitely better defined as L1CTL.
>
> I think Andreas Eversberg, Dieter Spaar or Sylvain Munaut would be good
> candidates to take care of the implementation, in case you're looking
> for somebody to take on that project.
>
> Regards,
> ? ? ? ?Harald
> --
> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>



-- 
Regards,
Alexander Chemeris.



From karnatinagesh at gmail.com  Wed Sep  7 06:12:56 2011
From: karnatinagesh at gmail.com (nageswara reddy)
Date: Wed, 7 Sep 2011 11:42:56 +0530
Subject: Not able to connect to Network using C-115 devices.
Message-ID: <CADXgi=egeX-sFfKr6mauZqnzFy4JPAyBUnbb66qD2R67pgOqOQ@mail.gmail.com>

Hi,

Finally i am able to compile the GSM Stack code and flash into the Motorol
Device C-115.
i can see the "layer1.bin" on the display, but my device is not latched on
to the N/W.


   - When i ran the HOST software of Mobile. i can see that SIM reader code
   is not working, and i can see the IMEI is hardcoded to "0000000000000000".
   - i captured the response of FBSB(Frequency and Time synchronization
   Burst), the result is comming as "255".


can any one please help me how to resolve these issues so that i can latch
on to the N/W.


regards,
nageswara reddy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110907/303f3048/attachment.htm>

From screaming-pain at libero.it  Wed Sep  7 16:18:55 2011
From: screaming-pain at libero.it (screaming-pain)
Date: Wed, 7 Sep 2011 09:18:55 -0700 (PDT)
Subject: Not able to connect to Network using C-115 devices.
In-Reply-To: <CADXgi=egeX-sFfKr6mauZqnzFy4JPAyBUnbb66qD2R67pgOqOQ@mail.gmail.com>
References: <CADXgi=egeX-sFfKr6mauZqnzFy4JPAyBUnbb66qD2R67pgOqOQ@mail.gmail.com>
Message-ID: <1315412335377-3317189.post@n3.nabble.com>

To use a real sim you need the sylvain/testing branch I think.
Once you have mobile running, open telnet and type the following:

enable
config t
ms 1
sim reader
no shutdown
write

Note: this is from what I remember but check the wiki and old posts in the
mailing list for confirmation
(you might need to shutdown and then bring the mobile back up after the sim
reader command)

Regards,
Loretta

Ps. My c115 with the testing branch attaches to the network, I've never
managed to make the call work though.

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Not-able-to-connect-to-Network-using-C-115-devices-tp3316437p3317189.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From karnatinagesh at gmail.com  Thu Sep  8 12:37:18 2011
From: karnatinagesh at gmail.com (karnatinagesh at gmail.com)
Date: Thu, 8 Sep 2011 05:37:18 -0700 (PDT)
Subject: Not able to connect to Network using C-115 devices.
In-Reply-To: <1315412335377-3317189.post@n3.nabble.com>
References: <CADXgi=egeX-sFfKr6mauZqnzFy4JPAyBUnbb66qD2R67pgOqOQ@mail.gmail.com>
	<1315412335377-3317189.post@n3.nabble.com>
Message-ID: <1315485438711-3319524.post@n3.nabble.com>

Hi screaming-pain,

i tried the way u mentioned. but still i am not able to latch on to the N/W.
Please find below the Logs.

nagesh at nagesh:~/osmocom-bb/src/host/layer23/src/mobile$ ./mobile -i
127.0.0.1
Copyright (C) 2008-2010 ...
Contributions by ...

License GPLv2+: GNU GPL version 2 or later
&lt;http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

VTY available on port 4247.
No Mobile Station defined, creating: MS '1'
<000f> sim.c:1206 init SIM client
<0006> gsm48_cc.c:61 init Call Control
<0001> gsm48_rr.c:5095 init Radio Ressource process
<0005> gsm48_mm.c:1312 init Mobility Management process
<0005> gsm48_mm.c:1035 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:5023 init PLMN process
<0003> gsm322.c:5024 init Cell Selection process
***
Warning: Mobile '1' has default IMEI: 000000000000000
This could relate your identitiy to other users with default IMEI.
***
Mobile '1' initialized, please start phone now!
<0002> gsm322.c:3804 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN
selection in state 'A0 null'
<000e> gsm322.c:1356 SIM is removed
<0002> gsm322.c:1357 SIM is removed
<0002> gsm322.c:800 new state 'A0 null' -> 'A6 no SIM inserted'
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in
state 'C0 null'
<0003> gsm322.c:3700 Switch on without SIM.
<0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (0..0)
<0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
<0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
first! Please fix prim_pm.c
^A<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (955..955)
<0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2812 Found no frequency.
<0003> gsm322.c:2124 Cell search finished without result.
<0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
selection in state 'A6 no SIM inserted'
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
in state 'C0 null'
<0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (0..0)
<0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
state MM IDLE, PLMN search
<0005> gsm48_mm.c:907 new MM IDLE state PLMN search -> no cell available
<0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
<0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (955..955)
<0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2812 Found no frequency.
<0003> gsm322.c:2124 Cell search finished without result.
<0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
selection in state 'A6 no SIM inserted'
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
in state 'C0 null'
<0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (0..0)
<0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
state MM IDLE, no cell available
<0005> gsm48_mm.c:4201 Message unhandled at this state.
<0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
<0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (955..955)
<0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2812 Found no frequency.
<0003> gsm322.c:2124 Cell search finished without result.
<0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
selection in state 'A6 no SIM inserted'
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
in state 'C0 null'
<0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (0..0)
<0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
state MM IDLE, no cell available
<0005> gsm48_mm.c:4201 Message unhandled at this state.
<0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
<0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (955..955)
<0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2812 Found no frequency.
<0003> gsm322.c:2124 Cell search finished without result.
<0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
selection in state 'A6 no SIM inserted'
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
in state 'C0 null'
<0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (0..0)
<0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
state MM IDLE, no cell available
<0005> gsm48_mm.c:4201 Message unhandled at this state.
<0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2900 Found signal (ARFCN 33 rxlev -103 (7))
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
<0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
first! Please fix prim_pm.c



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Not-able-to-connect-to-Network-using-C-115-devices-tp3316437p3319524.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From pabftk at gmail.com  Thu Sep  8 13:38:25 2011
From: pabftk at gmail.com (Pavel Baturko)
Date: Thu, 8 Sep 2011 17:38:25 +0400
Subject: Not able to connect to Network using C-115 devices.
In-Reply-To: <1315485438711-3319524.post@n3.nabble.com>
References: <CADXgi=egeX-sFfKr6mauZqnzFy4JPAyBUnbb66qD2R67pgOqOQ@mail.gmail.com>
	<1315412335377-3317189.post@n3.nabble.com>
	<1315485438711-3319524.post@n3.nabble.com>
Message-ID: <CAOBKM0-HiT+QehTG4okTFEW9vhNj73OrXCtn+6i66AYRprCS4Q@mail.gmail.com>

Hi,

Did you use the sylvain/testing branch and compile firmware with TX support?
Also as I see from
>No Mobile Station defined, creating: MS '1'
you have not config for mobile, may be you should create it in
~/.osmocom/bb/osmocom.cfg and define config for ms 1 with 'sim reader',
'network-selection-mode auto' and 'no shutdown' options. Or do it in console
as Loretta says.

PS: I'm new to Osmocom BB, so it's just my first steps with this project. I
use C118 and C115 and they could connect to network and make calls.

~Pavel

On Thu, Sep 8, 2011 at 4:37 PM, karnatinagesh at gmail.com <
karnatinagesh at gmail.com> wrote:

> Hi screaming-pain,
>
> i tried the way u mentioned. but still i am not able to latch on to the
> N/W.
> Please find below the Logs.
>
> nagesh at nagesh:~/osmocom-bb/src/host/layer23/src/mobile$ ./mobile -i
> 127.0.0.1
> Copyright (C) 2008-2010 ...
> Contributions by ...
>
> License GPLv2+: GNU GPL version 2 or later
> &lt;http://gnu.org/licenses/gpl.html&gt;
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> VTY available on port 4247.
> No Mobile Station defined, creating: MS '1'
> <000f> sim.c:1206 init SIM client
> <0006> gsm48_cc.c:61 init Call Control
> <0001> gsm48_rr.c:5095 init Radio Ressource process
> <0005> gsm48_mm.c:1312 init Mobility Management process
> <0005> gsm48_mm.c:1035 Selecting PLMN SEARCH state, because no SIM.
> <0002> gsm322.c:5023 init PLMN process
> <0003> gsm322.c:5024 init Cell Selection process
> ***
> Warning: Mobile '1' has default IMEI: 000000000000000
> This could relate your identitiy to other users with default IMEI.
> ***
> Mobile '1' initialized, please start phone now!
> <0002> gsm322.c:3804 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN
> selection in state 'A0 null'
> <000e> gsm322.c:1356 SIM is removed
> <0002> gsm322.c:1357 SIM is removed
> <0002> gsm322.c:800 new state 'A0 null' -> 'A6 no SIM inserted'
> <0003> gsm322.c:4035 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in
> state 'C0 null'
> <0003> gsm322.c:3700 Switch on without SIM.
> <0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (0..0)
> <0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
> <0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
> first! Please fix prim_pm.c
> ^A<0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (955..955)
> <0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2812 Found no frequency.
> <0003> gsm322.c:2124 Cell search finished without result.
> <0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
> <0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
> selection in state 'A6 no SIM inserted'
> <0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
> in state 'C0 null'
> <0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (0..0)
> <0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
> state MM IDLE, PLMN search
> <0005> gsm48_mm.c:907 new MM IDLE state PLMN search -> no cell available
> <0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
> <0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
> first! Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (955..955)
> <0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2812 Found no frequency.
> <0003> gsm322.c:2124 Cell search finished without result.
> <0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
> <0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
> selection in state 'A6 no SIM inserted'
> <0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
> in state 'C0 null'
> <0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (0..0)
> <0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
> state MM IDLE, no cell available
> <0005> gsm48_mm.c:4201 Message unhandled at this state.
> <0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
> <0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
> first! Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (955..955)
> <0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2812 Found no frequency.
> <0003> gsm322.c:2124 Cell search finished without result.
> <0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
> <0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
> selection in state 'A6 no SIM inserted'
> <0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
> in state 'C0 null'
> <0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (0..0)
> <0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
> state MM IDLE, no cell available
> <0005> gsm48_mm.c:4201 Message unhandled at this state.
> <0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
> <0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
> first! Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (955..955)
> <0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2812 Found no frequency.
> <0003> gsm322.c:2124 Cell search finished without result.
> <0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
> <0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
> selection in state 'A6 no SIM inserted'
> <0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
> in state 'C0 null'
> <0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (0..0)
> <0005> gsm48_mm.c:4188 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
> state MM IDLE, no cell available
> <0005> gsm48_mm.c:4201 Message unhandled at this state.
> <0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
> Please fix prim_pm.c
> <0003> gsm322.c:2900 Found signal (ARFCN 33 rxlev -103 (7))
> <0003> gsm322.c:2912 Done with power scanning range.
> <0003> gsm322.c:2790 Scanning power for all frequencies.
> <0003> gsm322.c:2851 Scanning frequencies. (512(DCS)..512(DCS))
> <0003> gsm322.c:2888 Getting PM for ARFCN 512(DCS) twice. Overwriting the
> first! Please fix prim_pm.c
>
>
>
> --
> View this message in context:
> http://baseband-devel.722152.n3.nabble.com/Not-able-to-connect-to-Network-using-C-115-devices-tp3316437p3319524.html
> Sent from the baseband-devel mailing list archive at Nabble.com.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110908/f16b7660/attachment.htm>

From josephli1029 at hotmail.com  Thu Sep  8 03:15:13 2011
From: josephli1029 at hotmail.com (josephli)
Date: Wed, 7 Sep 2011 20:15:13 -0700 (PDT)
Subject: How to change the log setting through vty?
Message-ID: <1315451713244-3318583.post@n3.nabble.com>

Hello,

I have got the logging details of all c files in the directory
../layer23/src/mobile. And now I also want to check the log in the directory
of layer23/src/common/lapdm.c. I found the file logging_vty.c is similar to
interface_vty.c so I tried several times but it didnt work. 

Can any one guide me how to use the vty to change the logging setting?

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/How-to-change-the-log-setting-through-vty-tp3318583p3318583.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From catchall at blombo.de  Sat Sep 10 08:38:48 2011
From: catchall at blombo.de (Martin Auer)
Date: Sat, 10 Sep 2011 10:38:48 +0200
Subject: Build fails on OSX Lion
Message-ID: <AF17C8F1-3405-472E-B8C6-12935BE7C537@blombo.de>

Hi,

when I try to build osmocombb on OSX Lion with MacPorts it fails because it cannot find linux/serial.h.  

I think it is needed to set some data rate for RS232? Is there a way to overcome this for OSX?

Thanks in advance,
Martin

../../src/serial.c:41:26: error: linux/serial.h: No such file or directory

bash-3.2# make -e CROSS_TOOL_PREFIX=arm-elf-gcc-4.6
cd shared/libosmocore && autoreconf -i
glibtoolize: putting auxiliary files in `.'.
glibtoolize: copying file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:14: installing `./config.sub'
configure.ac:5: installing `./missing'
configure.ac:5: installing `./install-sh'
configure.ac:14: installing `./config.guess'
src/Makefile.am: installing `./depcomp'
mkdir shared/libosmocore/build-target
cd shared/libosmocore/build-target && ../configure \
			--host=arm-elf --enable-embedded --disable-shared \
			--disable-tests ac_cv_header_sys_select_h=no \
			--disable-tests ac_cv_header_sys_socket_h=no \
		CFLAGS="-Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs"
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ../install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for arm-elf-strip... arm-elf-strip
checking whether make sets $(MAKE)... (cached) yes
checking for arm-elf-gcc... arm-elf-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-elf-gcc accepts -g... yes
checking for arm-elf-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of arm-elf-gcc... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i386-apple-darwin11.1.0
checking host system type... arm-unknown-elf
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by arm-elf-gcc... /Volumes/Speicher/opt/local/arm-elf/bin/ld
checking if the linker (/Volumes/Speicher/opt/local/arm-elf/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /opt/local/bin//arm-elf-nm -B
checking the name lister (/opt/local/bin//arm-elf-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /Volumes/Speicher/opt/local/arm-elf/bin/ld option to reload object files... -r
checking for arm-elf-objdump... arm-elf-objdump
checking how to recognize dependent libraries... unknown
checking for arm-elf-ar... arm-elf-ar
checking for arm-elf-strip... (cached) arm-elf-strip
checking for arm-elf-ranlib... arm-elf-ranlib
checking command to parse /opt/local/bin//arm-elf-nm -B output from arm-elf-gcc object... ok
checking how to run the C preprocessor... arm-elf-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for objdir... .libs
checking if arm-elf-gcc supports -fno-rtti -fno-exceptions... no
checking for arm-elf-gcc option to produce PIC... -fPIC -DPIC
checking if arm-elf-gcc PIC flag -fPIC -DPIC works... yes
checking if arm-elf-gcc static flag -static works... yes
checking if arm-elf-gcc supports -c -o file.o... yes
checking if arm-elf-gcc supports -c -o file.o... (cached) yes
checking whether the arm-elf-gcc linker (/Volumes/Speicher/opt/local/arm-elf/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking execinfo.h usability... no
checking execinfo.h presence... no
checking for execinfo.h... no
checking for sys/select.h... (cached) no
checking for sys/socket.h... (cached) no
checking syslog.h usability... no
checking syslog.h presence... no
checking for syslog.h... no
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking for doxygen... false
checking if arm-elf-gcc supports -fvisibility=hidden... yes
configure: creating ./config.status
config.status: creating libosmocore.pc
config.status: creating libosmocodec.pc
config.status: creating libosmovty.pc
config.status: creating libosmogsm.pc
config.status: creating include/osmocom/Makefile
config.status: creating include/osmocom/vty/Makefile
config.status: creating include/osmocom/codec/Makefile
config.status: creating include/osmocom/crypt/Makefile
config.status: creating include/osmocom/gsm/Makefile
config.status: creating include/osmocom/gsm/protocol/Makefile
config.status: creating include/osmocom/core/Makefile
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating src/vty/Makefile
config.status: creating src/codec/Makefile
config.status: creating src/gsm/Makefile
config.status: creating tests/Makefile
config.status: creating tests/timer/Makefile
config.status: creating tests/sms/Makefile
config.status: creating tests/msgfile/Makefile
config.status: creating tests/ussd/Makefile
config.status: creating tests/smscb/Makefile
config.status: creating tests/bits/Makefile
config.status: creating utils/Makefile
config.status: creating Doxyfile.core
config.status: creating Doxyfile.gsm
config.status: creating Doxyfile.vty
config.status: creating Doxyfile.codec
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
cd shared/libosmocore/build-target && make
echo UNKNOWN > ../.version-t && mv ../.version-t ../.version
make  all-recursive
Making all in include
Making all in osmocom
Making all in codec
make[5]: Nothing to be done for `all'.
Making all in crypt
make[5]: Nothing to be done for `all'.
Making all in gsm
Making all in protocol
make[6]: Nothing to be done for `all'.
make[6]: Nothing to be done for `all-am'.
Making all in core
make[5]: Nothing to be done for `all'.
make[5]: Nothing to be done for `all-am'.
make[4]: Nothing to be done for `all-am'.
Making all in src
Making all in .
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT timer.lo -MD -MP -MF .deps/timer.Tpo -c -o timer.lo ../../src/timer.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT timer.lo -MD -MP -MF .deps/timer.Tpo -c ../../src/timer.c -o timer.o
mv -f .deps/timer.Tpo .deps/timer.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT select.lo -MD -MP -MF .deps/select.Tpo -c -o select.lo ../../src/select.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT select.lo -MD -MP -MF .deps/select.Tpo -c ../../src/select.c -o select.o
mv -f .deps/select.Tpo .deps/select.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT signal.lo -MD -MP -MF .deps/signal.Tpo -c -o signal.lo ../../src/signal.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT signal.lo -MD -MP -MF .deps/signal.Tpo -c ../../src/signal.c -o signal.o
mv -f .deps/signal.Tpo .deps/signal.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT msgb.lo -MD -MP -MF .deps/msgb.Tpo -c -o msgb.lo ../../src/msgb.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT msgb.lo -MD -MP -MF .deps/msgb.Tpo -c ../../src/msgb.c -o msgb.o
mv -f .deps/msgb.Tpo .deps/msgb.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT bits.lo -MD -MP -MF .deps/bits.Tpo -c -o bits.lo ../../src/bits.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT bits.lo -MD -MP -MF .deps/bits.Tpo -c ../../src/bits.c -o bits.o
mv -f .deps/bits.Tpo .deps/bits.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT bitvec.lo -MD -MP -MF .deps/bitvec.Tpo -c -o bitvec.lo ../../src/bitvec.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT bitvec.lo -MD -MP -MF .deps/bitvec.Tpo -c ../../src/bitvec.c -o bitvec.o
mv -f .deps/bitvec.Tpo .deps/bitvec.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT statistics.lo -MD -MP -MF .deps/statistics.Tpo -c -o statistics.lo ../../src/statistics.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT statistics.lo -MD -MP -MF .deps/statistics.Tpo -c ../../src/statistics.c -o statistics.o
../../src/statistics.c: In function 'osmo_counter_get_by_name':
../../src/statistics.c:72:3: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration]
mv -f .deps/statistics.Tpo .deps/statistics.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT write_queue.lo -MD -MP -MF .deps/write_queue.Tpo -c -o write_queue.lo ../../src/write_queue.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT write_queue.lo -MD -MP -MF .deps/write_queue.Tpo -c ../../src/write_queue.c -o write_queue.o
mv -f .deps/write_queue.Tpo .deps/write_queue.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c -o utils.lo ../../src/utils.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c ../../src/utils.c -o utils.o
../../src/utils.c: In function 'get_value_string':
../../src/utils.c:33:2: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' [-Wformat]
../../src/utils.c: In function 'get_string_value':
../../src/utils.c:49:3: warning: implicit declaration of function 'strcasecmp' [-Wimplicit-function-declaration]
mv -f .deps/utils.Tpo .deps/utils.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT socket.lo -MD -MP -MF .deps/socket.Tpo -c -o socket.lo ../../src/socket.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT socket.lo -MD -MP -MF .deps/socket.Tpo -c ../../src/socket.c -o socket.o
mv -f .deps/socket.Tpo .deps/socket.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT logging.lo -MD -MP -MF .deps/logging.Tpo -c -o logging.lo ../../src/logging.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT logging.lo -MD -MP -MF .deps/logging.Tpo -c ../../src/logging.c -o logging.o
../../src/logging.c: In function 'log_parse_category_mask':
../../src/logging.c:162:2: warning: implicit declaration of function 'strdup' [-Wimplicit-function-declaration]
../../src/logging.c:162:15: warning: incompatible implicit declaration of built-in function 'strdup' [enabled by default]
../../src/logging.c:169:2: warning: implicit declaration of function 'strtok' [-Wimplicit-function-declaration]
../../src/logging.c:169:17: warning: assignment makes pointer from integer without a cast [enabled by default]
../../src/logging.c:172:4: warning: implicit declaration of function 'strstr' [-Wimplicit-function-declaration]
../../src/logging.c:172:18: warning: incompatible implicit declaration of built-in function 'strstr' [enabled by default]
../../src/logging.c:197:27: warning: assignment makes pointer from integer without a cast [enabled by default]
../../src/logging.c: In function '_file_output':
../../src/logging.c:427:2: warning: implicit declaration of function 'fprintf' [-Wimplicit-function-declaration]
../../src/logging.c:427:2: warning: incompatible implicit declaration of built-in function 'fprintf' [enabled by default]
../../src/logging.c:428:2: warning: implicit declaration of function 'fflush' [-Wimplicit-function-declaration]
../../src/logging.c: In function 'log_target_create_file':
../../src/logging.c:500:2: warning: implicit declaration of function 'fopen' [-Wimplicit-function-declaration]
../../src/logging.c:500:23: warning: assignment makes pointer from integer without a cast [enabled by default]
../../src/logging.c: In function 'log_target_find':
../../src/logging.c:524:4: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration]
../../src/logging.c: In function 'log_target_destroy':
../../src/logging.c:546:4: warning: implicit declaration of function 'fclose' [-Wimplicit-function-declaration]
../../src/logging.c: In function 'log_target_file_reopen':
../../src/logging.c:559:23: warning: assignment makes pointer from integer without a cast [enabled by default]
mv -f .deps/logging.Tpo .deps/logging.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT logging_syslog.lo -MD -MP -MF .deps/logging_syslog.Tpo -c -o logging_syslog.lo ../../src/logging_syslog.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT logging_syslog.lo -MD -MP -MF .deps/logging_syslog.Tpo -c ../../src/logging_syslog.c -o logging_syslog.o
mv -f .deps/logging_syslog.Tpo .deps/logging_syslog.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT rate_ctr.lo -MD -MP -MF .deps/rate_ctr.Tpo -c -o rate_ctr.lo ../../src/rate_ctr.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT rate_ctr.lo -MD -MP -MF .deps/rate_ctr.Tpo -c ../../src/rate_ctr.c -o rate_ctr.o
../../src/rate_ctr.c: In function 'rate_ctr_get_group_by_name_idx':
../../src/rate_ctr.c:153:3: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration]
mv -f .deps/rate_ctr.Tpo .deps/rate_ctr.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsmtap_util.lo -MD -MP -MF .deps/gsmtap_util.Tpo -c -o gsmtap_util.lo ../../src/gsmtap_util.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsmtap_util.lo -MD -MP -MF .deps/gsmtap_util.Tpo -c ../../src/gsmtap_util.c -o gsmtap_util.o
mv -f .deps/gsmtap_util.Tpo .deps/gsmtap_util.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT crc16.lo -MD -MP -MF .deps/crc16.Tpo -c -o crc16.lo ../../src/crc16.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT crc16.lo -MD -MP -MF .deps/crc16.Tpo -c ../../src/crc16.c -o crc16.o
mv -f .deps/crc16.Tpo .deps/crc16.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT panic.lo -MD -MP -MF .deps/panic.Tpo -c -o panic.lo ../../src/panic.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT panic.lo -MD -MP -MF .deps/panic.Tpo -c ../../src/panic.c -o panic.o
mv -f .deps/panic.Tpo .deps/panic.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c -o backtrace.lo ../../src/backtrace.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../src/backtrace.c -o backtrace.o
mv -f .deps/backtrace.Tpo .deps/backtrace.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT conv.lo -MD -MP -MF .deps/conv.Tpo -c -o conv.lo ../../src/conv.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT conv.lo -MD -MP -MF .deps/conv.Tpo -c ../../src/conv.c -o conv.o
mv -f .deps/conv.Tpo .deps/conv.Plo
/bin/sh ../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT application.lo -MD -MP -MF .deps/application.Tpo -c -o application.lo ../../src/application.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT application.lo -MD -MP -MF .deps/application.Tpo -c ../../src/application.c -o application.o
mv -f .deps/application.Tpo .deps/application.Plo
/bin/sh ../libtool --tag=CC   --mode=link arm-elf-gcc -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -version-info 2:0:0  -o libosmocore.la -rpath /usr/local/lib timer.lo select.lo signal.lo msgb.lo bits.lo bitvec.lo statistics.lo write_queue.lo utils.lo socket.lo logging.lo logging_syslog.lo rate_ctr.lo gsmtap_util.lo crc16.lo panic.lo backtrace.lo conv.lo application.lo      
libtool: link: arm-elf-ar cru .libs/libosmocore.a  timer.o select.o signal.o msgb.o bits.o bitvec.o statistics.o write_queue.o utils.o socket.o logging.o logging_syslog.o rate_ctr.o gsmtap_util.o crc16.o panic.o backtrace.o conv.o application.o
libtool: link: arm-elf-ranlib .libs/libosmocore.a
libtool: link: ( cd ".libs" && rm -f "libosmocore.la" && ln -s "../libosmocore.la" "libosmocore.la" )
Making all in vty
make[4]: Nothing to be done for `all'.
Making all in codec
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm610.lo -MD -MP -MF .deps/gsm610.Tpo -c -o gsm610.lo ../../../src/codec/gsm610.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm610.lo -MD -MP -MF .deps/gsm610.Tpo -c ../../../src/codec/gsm610.c -o gsm610.o
mv -f .deps/gsm610.Tpo .deps/gsm610.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm620.lo -MD -MP -MF .deps/gsm620.Tpo -c -o gsm620.lo ../../../src/codec/gsm620.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm620.lo -MD -MP -MF .deps/gsm620.Tpo -c ../../../src/codec/gsm620.c -o gsm620.o
mv -f .deps/gsm620.Tpo .deps/gsm620.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm660.lo -MD -MP -MF .deps/gsm660.Tpo -c -o gsm660.lo ../../../src/codec/gsm660.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm660.lo -MD -MP -MF .deps/gsm660.Tpo -c ../../../src/codec/gsm660.c -o gsm660.o
mv -f .deps/gsm660.Tpo .deps/gsm660.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm690.lo -MD -MP -MF .deps/gsm690.Tpo -c -o gsm690.lo ../../../src/codec/gsm690.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/codec -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm690.lo -MD -MP -MF .deps/gsm690.Tpo -c ../../../src/codec/gsm690.c -o gsm690.o
mv -f .deps/gsm690.Tpo .deps/gsm690.Plo
/bin/sh ../../libtool --tag=CC   --mode=link arm-elf-gcc -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs   -o libosmocodec.la -rpath /usr/local/lib gsm610.lo gsm620.lo gsm660.lo gsm690.lo  
libtool: link: arm-elf-ar cru .libs/libosmocodec.a  gsm610.o gsm620.o gsm660.o gsm690.o
libtool: link: arm-elf-ranlib .libs/libosmocodec.a
libtool: link: ( cd ".libs" && rm -f "libosmocodec.la" && ln -s "../libosmocodec.la" "libosmocodec.la" )
Making all in gsm
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT a5.lo -MD -MP -MF .deps/a5.Tpo -c -o a5.lo ../../../src/gsm/a5.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT a5.lo -MD -MP -MF .deps/a5.Tpo -c ../../../src/gsm/a5.c -o a5.o
mv -f .deps/a5.Tpo .deps/a5.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT rxlev_stat.lo -MD -MP -MF .deps/rxlev_stat.Tpo -c -o rxlev_stat.lo ../../../src/gsm/rxlev_stat.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT rxlev_stat.lo -MD -MP -MF .deps/rxlev_stat.Tpo -c ../../../src/gsm/rxlev_stat.c -o rxlev_stat.o
mv -f .deps/rxlev_stat.Tpo .deps/rxlev_stat.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT tlv_parser.lo -MD -MP -MF .deps/tlv_parser.Tpo -c -o tlv_parser.lo ../../../src/gsm/tlv_parser.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT tlv_parser.lo -MD -MP -MF .deps/tlv_parser.Tpo -c ../../../src/gsm/tlv_parser.c -o tlv_parser.o
mv -f .deps/tlv_parser.Tpo .deps/tlv_parser.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT comp128.lo -MD -MP -MF .deps/comp128.Tpo -c -o comp128.lo ../../../src/gsm/comp128.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT comp128.lo -MD -MP -MF .deps/comp128.Tpo -c ../../../src/gsm/comp128.c -o comp128.o
mv -f .deps/comp128.Tpo .deps/comp128.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm_utils.lo -MD -MP -MF .deps/gsm_utils.Tpo -c -o gsm_utils.lo ../../../src/gsm/gsm_utils.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm_utils.lo -MD -MP -MF .deps/gsm_utils.Tpo -c ../../../src/gsm/gsm_utils.c -o gsm_utils.o
../../../src/gsm/gsm_utils.c: In function 'gsm_7bit_encode':
../../../src/gsm/gsm_utils.c:253:13: warning: variable 'z' set but not used [-Wunused-but-set-variable]
mv -f .deps/gsm_utils.Tpo .deps/gsm_utils.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT rsl.lo -MD -MP -MF .deps/rsl.Tpo -c -o rsl.lo ../../../src/gsm/rsl.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT rsl.lo -MD -MP -MF .deps/rsl.Tpo -c ../../../src/gsm/rsl.c -o rsl.o
mv -f .deps/rsl.Tpo .deps/rsl.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm48.lo -MD -MP -MF .deps/gsm48.Tpo -c -o gsm48.lo ../../../src/gsm/gsm48.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm48.lo -MD -MP -MF .deps/gsm48.Tpo -c ../../../src/gsm/gsm48.c -o gsm48.o
../../../src/gsm/gsm48.c: In function 'gsm48_mi_to_string':
../../../src/gsm/gsm48.c:348:4: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' [-Wformat]
mv -f .deps/gsm48.Tpo .deps/gsm48.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm48_ie.lo -MD -MP -MF .deps/gsm48_ie.Tpo -c -o gsm48_ie.lo ../../../src/gsm/gsm48_ie.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm48_ie.lo -MD -MP -MF .deps/gsm48_ie.Tpo -c ../../../src/gsm/gsm48_ie.c -o gsm48_ie.o
mv -f .deps/gsm48_ie.Tpo .deps/gsm48_ie.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm0808.lo -MD -MP -MF .deps/gsm0808.Tpo -c -o gsm0808.lo ../../../src/gsm/gsm0808.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm0808.lo -MD -MP -MF .deps/gsm0808.Tpo -c ../../../src/gsm/gsm0808.c -o gsm0808.o
mv -f .deps/gsm0808.Tpo .deps/gsm0808.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT sysinfo.lo -MD -MP -MF .deps/sysinfo.Tpo -c -o sysinfo.lo ../../../src/gsm/sysinfo.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT sysinfo.lo -MD -MP -MF .deps/sysinfo.Tpo -c ../../../src/gsm/sysinfo.c -o sysinfo.o
mv -f .deps/sysinfo.Tpo .deps/sysinfo.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gprs_cipher_core.lo -MD -MP -MF .deps/gprs_cipher_core.Tpo -c -o gprs_cipher_core.lo ../../../src/gsm/gprs_cipher_core.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gprs_cipher_core.lo -MD -MP -MF .deps/gprs_cipher_core.Tpo -c ../../../src/gsm/gprs_cipher_core.c -o gprs_cipher_core.o
mv -f .deps/gprs_cipher_core.Tpo .deps/gprs_cipher_core.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm0480.lo -MD -MP -MF .deps/gsm0480.Tpo -c -o gsm0480.lo ../../../src/gsm/gsm0480.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm0480.lo -MD -MP -MF .deps/gsm0480.Tpo -c ../../../src/gsm/gsm0480.c -o gsm0480.o
../../../src/gsm/gsm0480.c: In function 'parse_process_uss_req':
../../../src/gsm/gsm0480.c:405:7: warning: pointer targets in passing argument 1 of 'gsm_7bit_decode' differ in signedness [-Wpointer-sign]
../../../include/osmocom/gsm/gsm_utils.h:59:5: note: expected 'char *' but argument is of type 'uint8_t *'
mv -f .deps/gsm0480.Tpo .deps/gsm0480.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT abis_nm.lo -MD -MP -MF .deps/abis_nm.Tpo -c -o abis_nm.lo ../../../src/gsm/abis_nm.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT abis_nm.lo -MD -MP -MF .deps/abis_nm.Tpo -c ../../../src/gsm/abis_nm.c -o abis_nm.o
mv -f .deps/abis_nm.Tpo .deps/abis_nm.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm0502.lo -MD -MP -MF .deps/gsm0502.Tpo -c -o gsm0502.lo ../../../src/gsm/gsm0502.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT gsm0502.lo -MD -MP -MF .deps/gsm0502.Tpo -c ../../../src/gsm/gsm0502.c -o gsm0502.o
mv -f .deps/gsm0502.Tpo .deps/gsm0502.Plo
/bin/sh ../../libtool --tag=CC   --mode=compile arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm  -I../../../include   -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT lapdm.lo -MD -MP -MF .deps/lapdm.Tpo -c -o lapdm.lo ../../../src/gsm/lapdm.c
libtool: compile:  arm-elf-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../src/gsm -I../../../include -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -MT lapdm.lo -MD -MP -MF .deps/lapdm.Tpo -c ../../../src/gsm/lapdm.c -o lapdm.o
../../../src/gsm/lapdm.c: In function 'lapdm_t200_cb':
../../../src/gsm/lapdm.c:608:2: warning: format '%u' expects argument of type 'unsigned int', but argument 8 has type 'uint32_t' [-Wformat]
../../../src/gsm/lapdm.c:710:3: warning: format '%u' expects argument of type 'unsigned int', but argument 7 has type 'uint32_t' [-Wformat]
../../../src/gsm/lapdm.c: In function 'lapdm_rx_u':
../../../src/gsm/lapdm.c:1136:5: warning: implicit declaration of function 'memcmp' [-Wimplicit-function-declaration]
../../../src/gsm/lapdm.c: In function 'rslms_rx_rll_est_req':
../../../src/gsm/lapdm.c:1800:12: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
../../../src/gsm/lapdm.c: In function 'rslms_rx_rll_udata_req':
../../../src/gsm/lapdm.c:1892:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
../../../src/gsm/lapdm.c: In function 'rslms_rx_rll_data_req':
../../../src/gsm/lapdm.c:1934:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
mv -f .deps/lapdm.Tpo .deps/lapdm.Plo
/bin/sh ../../libtool --tag=CC   --mode=link arm-elf-gcc -fPIC -Wall -Os -ffunction-sections -I/opt/local/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs -version-info 1:0:0  -o libosmogsm.la -rpath /usr/local/lib a5.lo rxlev_stat.lo tlv_parser.lo comp128.lo gsm_utils.lo rsl.lo gsm48.lo gsm48_ie.lo gsm0808.lo sysinfo.lo gprs_cipher_core.lo gsm0480.lo abis_nm.lo gsm0502.lo lapdm.lo ../../src/libosmocore.la 
libtool: link: arm-elf-ar cru .libs/libosmogsm.a  a5.o rxlev_stat.o tlv_parser.o comp128.o gsm_utils.o rsl.o gsm48.o gsm48_ie.o gsm0808.o sysinfo.o gprs_cipher_core.o gsm0480.o abis_nm.o gsm0502.o lapdm.o
libtool: link: arm-elf-ranlib .libs/libosmogsm.a
libtool: link: ( cd ".libs" && rm -f "libosmogsm.la" && ln -s "../libosmogsm.la" "libosmogsm.la" )
Making all in tests
make[4]: Nothing to be done for `all-am'.
Making all in utils
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
mkdir shared/libosmocore/build-host
cd shared/libosmocore/build-host && ../configure 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ../install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i386-apple-darwin11.1.0
checking host system type... i386-apple-darwin11.1.0
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin11.1.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking execinfo.h usability... yes
checking execinfo.h presence... yes
checking for execinfo.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking for doxygen... false
checking if gcc supports -fvisibility=hidden... yes
configure: creating ./config.status
config.status: creating libosmocore.pc
config.status: creating libosmocodec.pc
config.status: creating libosmovty.pc
config.status: creating libosmogsm.pc
config.status: creating include/osmocom/Makefile
config.status: creating include/osmocom/vty/Makefile
config.status: creating include/osmocom/codec/Makefile
config.status: creating include/osmocom/crypt/Makefile
config.status: creating include/osmocom/gsm/Makefile
config.status: creating include/osmocom/gsm/protocol/Makefile
config.status: creating include/osmocom/core/Makefile
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating src/vty/Makefile
config.status: creating src/codec/Makefile
config.status: creating src/gsm/Makefile
config.status: creating tests/Makefile
config.status: creating tests/timer/Makefile
config.status: creating tests/sms/Makefile
config.status: creating tests/msgfile/Makefile
config.status: creating tests/ussd/Makefile
config.status: creating tests/smscb/Makefile
config.status: creating tests/bits/Makefile
config.status: creating utils/Makefile
config.status: creating Doxyfile.core
config.status: creating Doxyfile.gsm
config.status: creating Doxyfile.vty
config.status: creating Doxyfile.codec
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
cd shared/libosmocore/build-host && make
make  all-recursive
Making all in include
Making all in osmocom
Making all in vty
make[5]: Nothing to be done for `all'.
Making all in codec
make[5]: Nothing to be done for `all'.
Making all in crypt
make[5]: Nothing to be done for `all'.
Making all in gsm
Making all in protocol
make[6]: Nothing to be done for `all'.
make[6]: Nothing to be done for `all-am'.
Making all in core
make[5]: Nothing to be done for `all'.
make[5]: Nothing to be done for `all-am'.
make[4]: Nothing to be done for `all-am'.
Making all in src
Making all in .
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT timer.lo -MD -MP -MF .deps/timer.Tpo -c -o timer.lo ../../src/timer.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT timer.lo -MD -MP -MF .deps/timer.Tpo -c ../../src/timer.c  -fno-common -DPIC -o .libs/timer.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT timer.lo -MD -MP -MF .deps/timer.Tpo -c ../../src/timer.c -o timer.o >/dev/null 2>&1
mv -f .deps/timer.Tpo .deps/timer.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT select.lo -MD -MP -MF .deps/select.Tpo -c -o select.lo ../../src/select.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT select.lo -MD -MP -MF .deps/select.Tpo -c ../../src/select.c  -fno-common -DPIC -o .libs/select.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT select.lo -MD -MP -MF .deps/select.Tpo -c ../../src/select.c -o select.o >/dev/null 2>&1
mv -f .deps/select.Tpo .deps/select.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT signal.lo -MD -MP -MF .deps/signal.Tpo -c -o signal.lo ../../src/signal.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT signal.lo -MD -MP -MF .deps/signal.Tpo -c ../../src/signal.c  -fno-common -DPIC -o .libs/signal.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT signal.lo -MD -MP -MF .deps/signal.Tpo -c ../../src/signal.c -o signal.o >/dev/null 2>&1
mv -f .deps/signal.Tpo .deps/signal.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT msgb.lo -MD -MP -MF .deps/msgb.Tpo -c -o msgb.lo ../../src/msgb.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT msgb.lo -MD -MP -MF .deps/msgb.Tpo -c ../../src/msgb.c  -fno-common -DPIC -o .libs/msgb.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT msgb.lo -MD -MP -MF .deps/msgb.Tpo -c ../../src/msgb.c -o msgb.o >/dev/null 2>&1
mv -f .deps/msgb.Tpo .deps/msgb.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT bits.lo -MD -MP -MF .deps/bits.Tpo -c -o bits.lo ../../src/bits.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT bits.lo -MD -MP -MF .deps/bits.Tpo -c ../../src/bits.c  -fno-common -DPIC -o .libs/bits.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT bits.lo -MD -MP -MF .deps/bits.Tpo -c ../../src/bits.c -o bits.o >/dev/null 2>&1
mv -f .deps/bits.Tpo .deps/bits.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT bitvec.lo -MD -MP -MF .deps/bitvec.Tpo -c -o bitvec.lo ../../src/bitvec.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT bitvec.lo -MD -MP -MF .deps/bitvec.Tpo -c ../../src/bitvec.c  -fno-common -DPIC -o .libs/bitvec.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT bitvec.lo -MD -MP -MF .deps/bitvec.Tpo -c ../../src/bitvec.c -o bitvec.o >/dev/null 2>&1
mv -f .deps/bitvec.Tpo .deps/bitvec.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT statistics.lo -MD -MP -MF .deps/statistics.Tpo -c -o statistics.lo ../../src/statistics.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT statistics.lo -MD -MP -MF .deps/statistics.Tpo -c ../../src/statistics.c  -fno-common -DPIC -o .libs/statistics.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT statistics.lo -MD -MP -MF .deps/statistics.Tpo -c ../../src/statistics.c -o statistics.o >/dev/null 2>&1
mv -f .deps/statistics.Tpo .deps/statistics.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT write_queue.lo -MD -MP -MF .deps/write_queue.Tpo -c -o write_queue.lo ../../src/write_queue.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT write_queue.lo -MD -MP -MF .deps/write_queue.Tpo -c ../../src/write_queue.c  -fno-common -DPIC -o .libs/write_queue.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT write_queue.lo -MD -MP -MF .deps/write_queue.Tpo -c ../../src/write_queue.c -o write_queue.o >/dev/null 2>&1
mv -f .deps/write_queue.Tpo .deps/write_queue.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c -o utils.lo ../../src/utils.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c ../../src/utils.c  -fno-common -DPIC -o .libs/utils.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT utils.lo -MD -MP -MF .deps/utils.Tpo -c ../../src/utils.c -o utils.o >/dev/null 2>&1
mv -f .deps/utils.Tpo .deps/utils.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT socket.lo -MD -MP -MF .deps/socket.Tpo -c -o socket.lo ../../src/socket.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT socket.lo -MD -MP -MF .deps/socket.Tpo -c ../../src/socket.c  -fno-common -DPIC -o .libs/socket.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT socket.lo -MD -MP -MF .deps/socket.Tpo -c ../../src/socket.c -o socket.o >/dev/null 2>&1
mv -f .deps/socket.Tpo .deps/socket.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT logging.lo -MD -MP -MF .deps/logging.Tpo -c -o logging.lo ../../src/logging.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT logging.lo -MD -MP -MF .deps/logging.Tpo -c ../../src/logging.c  -fno-common -DPIC -o .libs/logging.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT logging.lo -MD -MP -MF .deps/logging.Tpo -c ../../src/logging.c -o logging.o >/dev/null 2>&1
mv -f .deps/logging.Tpo .deps/logging.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT logging_syslog.lo -MD -MP -MF .deps/logging_syslog.Tpo -c -o logging_syslog.lo ../../src/logging_syslog.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT logging_syslog.lo -MD -MP -MF .deps/logging_syslog.Tpo -c ../../src/logging_syslog.c  -fno-common -DPIC -o .libs/logging_syslog.o
../../src/logging_syslog.c:47: warning: type qualifiers ignored on function return type
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT logging_syslog.lo -MD -MP -MF .deps/logging_syslog.Tpo -c ../../src/logging_syslog.c -o logging_syslog.o >/dev/null 2>&1
mv -f .deps/logging_syslog.Tpo .deps/logging_syslog.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT rate_ctr.lo -MD -MP -MF .deps/rate_ctr.Tpo -c -o rate_ctr.lo ../../src/rate_ctr.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT rate_ctr.lo -MD -MP -MF .deps/rate_ctr.Tpo -c ../../src/rate_ctr.c  -fno-common -DPIC -o .libs/rate_ctr.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT rate_ctr.lo -MD -MP -MF .deps/rate_ctr.Tpo -c ../../src/rate_ctr.c -o rate_ctr.o >/dev/null 2>&1
mv -f .deps/rate_ctr.Tpo .deps/rate_ctr.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT gsmtap_util.lo -MD -MP -MF .deps/gsmtap_util.Tpo -c -o gsmtap_util.lo ../../src/gsmtap_util.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT gsmtap_util.lo -MD -MP -MF .deps/gsmtap_util.Tpo -c ../../src/gsmtap_util.c  -fno-common -DPIC -o .libs/gsmtap_util.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT gsmtap_util.lo -MD -MP -MF .deps/gsmtap_util.Tpo -c ../../src/gsmtap_util.c -o gsmtap_util.o >/dev/null 2>&1
mv -f .deps/gsmtap_util.Tpo .deps/gsmtap_util.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT crc16.lo -MD -MP -MF .deps/crc16.Tpo -c -o crc16.lo ../../src/crc16.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT crc16.lo -MD -MP -MF .deps/crc16.Tpo -c ../../src/crc16.c  -fno-common -DPIC -o .libs/crc16.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT crc16.lo -MD -MP -MF .deps/crc16.Tpo -c ../../src/crc16.c -o crc16.o >/dev/null 2>&1
mv -f .deps/crc16.Tpo .deps/crc16.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT panic.lo -MD -MP -MF .deps/panic.Tpo -c -o panic.lo ../../src/panic.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT panic.lo -MD -MP -MF .deps/panic.Tpo -c ../../src/panic.c  -fno-common -DPIC -o .libs/panic.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT panic.lo -MD -MP -MF .deps/panic.Tpo -c ../../src/panic.c -o panic.o >/dev/null 2>&1
mv -f .deps/panic.Tpo .deps/panic.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c -o backtrace.lo ../../src/backtrace.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../src/backtrace.c  -fno-common -DPIC -o .libs/backtrace.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../src/backtrace.c -o backtrace.o >/dev/null 2>&1
mv -f .deps/backtrace.Tpo .deps/backtrace.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT conv.lo -MD -MP -MF .deps/conv.Tpo -c -o conv.lo ../../src/conv.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT conv.lo -MD -MP -MF .deps/conv.Tpo -c ../../src/conv.c  -fno-common -DPIC -o .libs/conv.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT conv.lo -MD -MP -MF .deps/conv.Tpo -c ../../src/conv.c -o conv.o >/dev/null 2>&1
mv -f .deps/conv.Tpo .deps/conv.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT application.lo -MD -MP -MF .deps/application.Tpo -c -o application.lo ../../src/application.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT application.lo -MD -MP -MF .deps/application.Tpo -c ../../src/application.c  -fno-common -DPIC -o .libs/application.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT application.lo -MD -MP -MF .deps/application.Tpo -c ../../src/application.c -o application.o >/dev/null 2>&1
mv -f .deps/application.Tpo .deps/application.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT plugin.lo -MD -MP -MF .deps/plugin.Tpo -c -o plugin.lo ../../src/plugin.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT plugin.lo -MD -MP -MF .deps/plugin.Tpo -c ../../src/plugin.c  -fno-common -DPIC -o .libs/plugin.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT plugin.lo -MD -MP -MF .deps/plugin.Tpo -c ../../src/plugin.c -o plugin.o >/dev/null 2>&1
mv -f .deps/plugin.Tpo .deps/plugin.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT talloc.lo -MD -MP -MF .deps/talloc.Tpo -c -o talloc.lo ../../src/talloc.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT talloc.lo -MD -MP -MF .deps/talloc.Tpo -c ../../src/talloc.c  -fno-common -DPIC -o .libs/talloc.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT talloc.lo -MD -MP -MF .deps/talloc.Tpo -c ../../src/talloc.c -o talloc.o >/dev/null 2>&1
mv -f .deps/talloc.Tpo .deps/talloc.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT msgfile.lo -MD -MP -MF .deps/msgfile.Tpo -c -o msgfile.lo ../../src/msgfile.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT msgfile.lo -MD -MP -MF .deps/msgfile.Tpo -c ../../src/msgfile.c  -fno-common -DPIC -o .libs/msgfile.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT msgfile.lo -MD -MP -MF .deps/msgfile.Tpo -c ../../src/msgfile.c -o msgfile.o >/dev/null 2>&1
mv -f .deps/msgfile.Tpo .deps/msgfile.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../../src  -I../../include   -fPIC -Wall -g -O2 -MT serial.lo -MD -MP -MF .deps/serial.Tpo -c -o serial.lo ../../src/serial.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I../../include -fPIC -Wall -g -O2 -MT serial.lo -MD -MP -MF .deps/serial.Tpo -c ../../src/serial.c  -fno-common -DPIC -o .libs/serial.o
../../src/serial.c:41:26: error: linux/serial.h: No such file or directory
../../src/serial.c: In function 'osmo_serial_set_custom_baudrate':
../../src/serial.c:159: error: storage size of 'ser_info' isn't known
../../src/serial.c:161: error: 'TIOCGSERIAL' undeclared (first use in this function)
../../src/serial.c:161: error: (Each undeclared identifier is reported only once
../../src/serial.c:161: error: for each function it appears in.)
../../src/serial.c:167: error: 'ASYNC_SPD_CUST' undeclared (first use in this function)
../../src/serial.c:167: error: 'ASYNC_LOW_LATENCY' undeclared (first use in this function)
../../src/serial.c:170: error: 'TIOCSSERIAL' undeclared (first use in this function)
../../src/serial.c:159: warning: unused variable 'ser_info'
../../src/serial.c: In function 'osmo_serial_clear_custom_baudrate':
../../src/serial.c:189: error: storage size of 'ser_info' isn't known
../../src/serial.c:191: error: 'TIOCGSERIAL' undeclared (first use in this function)
../../src/serial.c:197: error: 'ASYNC_LOW_LATENCY' undeclared (first use in this function)
../../src/serial.c:200: error: 'TIOCSSERIAL' undeclared (first use in this function)
../../src/serial.c:189: warning: unused variable 'ser_info'
make[4]: *** [serial.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [shared/libosmocore/build-host/src/.libs/libosmocore.la] Error 2


From roladunjoye at gmail.com  Tue Sep 13 03:00:55 2011
From: roladunjoye at gmail.com (rola)
Date: Mon, 12 Sep 2011 20:00:55 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
Message-ID: <1315882855532-3331557.post@n3.nabble.com>

Hi all,

I am really thrill to set up OsmocomBB program single handedly after
scourging through mailing list and crash learning linux environment from
online tutorials. This is an amazing project with a lot of concept and idea
that can only be acquired through years of working as a developer. I really
appreciate the great work each and everyone put into this project and I am
taking advantage of this to set myself back as a programmer.

Could there be a comprehensive documentation on how to setup the the project
from the first stage of firmware download to the linking of various
applications to the running osmocon program. It took a lot of time to get
myself around the project before I could finally set it up. Beside the core
participant programmers and those that were previously familiar with this
nature of application many of the interested enthusiast like me are left in
the dark on what to do at one point or the other during the set up of the
project.

For an instance after successfully setting up the osmocomBB, I couldn't run
the program with my C155 just for the fact that I mistakenly took the
passing parameter for  C155 for "C155xor" following the given example based
on C123. It took me over two days to realized where the error was all
because I was having legitimate error report of "NACK" that was explained on
the blog to be due to different transmission rate between the hosting system
and the MS onboard chip. By stroke of luck, I removed the "xor" based on
solution suggested for similar issue on different Motorola model and VIOLA
!!!  firmware completes downloading and I'm set on track . The funniest
thing is that it was after I've resolved the problem that I later read the
reference to the C155 parameter passing.

Secondly, setting up config file for MOBILE APP was like searching for
needle in the hail. My thought was that the file needed to contain a written
configuration of VTY with telnet parameters. That took me on a journey of
learning what telnet is, what Virtual Terminal is. Anyway, I learn a lot
from googling here and there before I finally read in some solution that the
file is just an empty file. I know that it might be trivial issue to many of
the grounded programmers but to some like me it was really a big issue.

Right now I am running the Mobile App and about to setup the patch 
wireshark but still have no clue of what command to send through the telnet
interface or what next to do on the Mobile prompt section. It will be a nice
to have a compiled possible errors that newbies might encounter and as well
a basic step on what to do at each stage of setting up  and running of the
programs.

Just to give a little background about myself; I have a two semester of
wireless technology as part of my graduate study and I intend to use
OsmocomBB as the basis of my thesis on analyzing GSM Um interface.

Great work guys and God bless.

Rasak

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3331557.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From roladunjoye at gmail.com  Wed Sep 14 00:21:04 2011
From: roladunjoye at gmail.com (rola)
Date: Tue, 13 Sep 2011 17:21:04 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1315882855532-3331557.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
Message-ID: <1315959664467-3334411.post@n3.nabble.com>

Like I mentioned earlier in my post that it took serious searching through
the mailing list to know what to do. I have done all what I think I am
expected to do but I'm yet to get cell information after using the SHOW CELL
1 command on the VTY.

Firstly, everything runs perfectly with respect to the Mobile App. I am
running the Mobile App with no SIM for now. I understand that Sylvian path
support SIM but I just want to see it run without SIM for now.

I will be so much grateful if anyone can just let me know what parameter to
set on VTY. Already I have written to the .cfg file and as well use 'conf t'
with 'ms 1' and 'no shutdown' parameters. For now, no traffic is displayed
by Wireshark despite of no error message in running of the Mobile.

I have looked thoroughly and couldn't find any info about displaying CELL
INFO with no SIM. I hope I get a response soon from anyone for me to finally
say EUREKA!!!

Best regards,

Rasak

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3334411.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From holger at freyther.de  Wed Sep 14 00:25:20 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 14 Sep 2011 02:25:20 +0200
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1315882855532-3331557.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
Message-ID: <4E6FF470.60502@freyther.de>

On 09/13/2011 05:00 AM, rola wrote:
> Hi all,

I can assist you with answering some docbook questions to help you to create a
usermanual and merge your doc into the osmocom-bb tree. Even if your question
has not been answered you might already have knowledge worth sharing.

cheers
	holger




From roladunjoye at gmail.com  Wed Sep 14 02:31:22 2011
From: roladunjoye at gmail.com (rola)
Date: Tue, 13 Sep 2011 19:31:22 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1315882855532-3331557.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
Message-ID: <1315967482773-3334622.post@n3.nabble.com>

Hi Holger, 

I will love to do that as my token contribution in a way but for now, I have
to get the Mobile App running. I have everything pretty much set up to the
level of being able to telnet to the Mobile. However, Wireshark is not
receiving any frame and Cell Info display empty content. I'm using No SIM
and running from the Master with Osmocon running on loader.compalram.bin. I
set the Mobile App to loop back 127.0.0.1 and set the Wireshark port to what
is on the wiki. Is there any other program I need to run beside Mobile
before I can receive cell broadcast info even though the init process shows
no error.

I really would have love to start looking into the code but that gonna be
like looking for pond in the middle of desert. If I can get this work out
with idea of how each and every programs involve interact, then I can start
playing around with source code and perhaps may be implements some GSM
features in the future.

By the way, how will the merging of existing code on OpenBTS integrate with
the OSmocomBB such that USRP is bypassed. I believe this can work if
appropriate framing is sent from the layer23 to layer1. I hope this will not
require writing special firmware to implement the Signal Channel from the
BST. By this, OsmocomBB could be the simplest GSM implementation ever with
total cost nothing less than $100.00

There may be concern about hopping frequency bu I think that has been taken
care of in one of the demonstration by using four different MS. But I would
know how the transmitting and receiving signal will handle at the layer.
Layer23 can then pass the received digitized voice using VoIP s it is in
OpenBTS. From the look of thing, OpenBSc might have the necessary code by
now but it will worth it can be independent of any specific device. That is
just what I feel initially about this work but I realized that it is a big
hell of a work for a newbie like me.

Please, if you can help out with my earlier request on retrieving the CELL
INFO when SHOW CELL command is used while Mobile App is running with no SIM
and Osmocon is strictly runs on Master, that will make my day.

Cheers.

Rasak

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3334622.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From holger at freyther.de  Wed Sep 14 12:00:52 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 14 Sep 2011 14:00:52 +0200
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1315967482773-3334622.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
	<1315967482773-3334622.post@n3.nabble.com>
Message-ID: <4E709774.6080203@freyther.de>

On 09/14/2011 04:31 AM, rola wrote:
> Hi Holger, 
> 
> I will love to do that as my token contribution in a way but for now, I have
> to get the Mobile App running.

Well, if you start with the documentation and bring it to a a point where you
have questions regarding the mobile app we can deal with it as part of the
documentation.

your choice

	holger



From roladunjoye at gmail.com  Wed Sep 14 14:55:18 2011
From: roladunjoye at gmail.com (rola)
Date: Wed, 14 Sep 2011 07:55:18 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <4E709774.6080203@freyther.de>
References: <1315882855532-3331557.post@n3.nabble.com>
	<1315967482773-3334622.post@n3.nabble.com>
	<4E709774.6080203@freyther.de>
Message-ID: <1316012118966-3336070.post@n3.nabble.com>

Holger,

You don't have to task me before you let me in the CLUB. I wish I can do
much more than you expect me but my hands are tight at the moment. I
understand how difficult for many to spare their time to contribute to this
project and I really feel the impact after gruesome time of resolving issues
single handedly. We all don't have to pass through the hard path to get
thing going because it is like reinventing the wheel. That is why I
requested for more user friendly directive for newbies like me. In the first
instance the existing wiki is old and misleading in some cases. You are well
aware that nothing like layer23 app anymore yet it is still reference in the
wiki. This sort of information creates a lot of confusion for in experience
people like me.

Anyway, I hope in a short while I will be posting my CELL INFO display cause
my MS is scanning at the moment.

Cheers.

Rasak  

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3336070.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From holger at freyther.de  Wed Sep 14 15:02:02 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 14 Sep 2011 17:02:02 +0200
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1316012118966-3336070.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>	<1315967482773-3334622.post@n3.nabble.com>	<4E709774.6080203@freyther.de>
	<1316012118966-3336070.post@n3.nabble.com>
Message-ID: <4E70C1EA.9030308@freyther.de>

On 09/14/2011 04:55 PM, rola wrote:
> Holger,

> That is why I
> requested for more user friendly directive for newbies like me. In the first
> instance the existing wiki is old and misleading in some cases. You are well
> aware that nothing like layer23 app anymore yet it is still reference in the
> wiki. This sort of information creates a lot of confusion for in experience
> people like me.

Well then either feel free to ask for a password for the wiki (it is our
manual spam filter) and change the config or point to the pages with outdated
information.

And it is not a 'CLUB' either you feel like sharing your work or you don't.

holger



From roladunjoye at gmail.com  Wed Sep 14 17:48:56 2011
From: roladunjoye at gmail.com (rola)
Date: Wed, 14 Sep 2011 10:48:56 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <4E70C1EA.9030308@freyther.de>
References: <1315882855532-3331557.post@n3.nabble.com>
	<1315967482773-3334622.post@n3.nabble.com>
	<4E709774.6080203@freyther.de>
	<1316012118966-3336070.post@n3.nabble.com>
	<4E70C1EA.9030308@freyther.de>
Message-ID: <1316022536497-3336592.post@n3.nabble.com>

Hi Holger,

You should know that for some it is not all that easy to trouble shoot
somebody else code when one has little idea of how thing is structure. I
have little or know idea of so many concepts used in developing this
application and that make it tough for me to hack into the program. I only
have basic understand of GSM network and a bit beginner's programming
experience. However I've tried all what I could to run it the way I
understand it. May be I was wrong in asking for more elaborate step by step
procedure that will create unnecessary mistake that might be committed by
people like me.

One thing you don't get to realized is that people like me normally base
their parameter on the first given working command and overlook a subtle
change in parameter when the same code is being used. For an instance I have
been using my initial loader.compal.bin for osmocon not knowing that it is
suppose to be layer1.*.bin. when running with Mobile. Believe me, I read the
wiki but my eyes never caught the difference until I ran into issues and
locate the difference in someone else posted debug. Time waisted in looking
all around the mailing list would have been used to work on something else.

Anyway, I'm still stuck at one point on what I am doing; both osmocon and
Mobile seems lock in an endless cycle of scanning the channel. Nothing can
be display for the CELL INFO. I hope you can just help out at this stage.

If I can get an access to the wiki and point out the section needed to be
modified with respect to the existing online documentation, it will be with
all pleasure to make a token of my assistance. Therefore, I hereby request
for the password to the wiki page.
Have a nice wonderful day.

Best regards

Rasak

> And it is not a 'CLUB' either you feel like sharing your work or you
> don't.


--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3336592.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From screaming-pain at libero.it  Wed Sep 14 22:19:20 2011
From: screaming-pain at libero.it (screaming-pain)
Date: Wed, 14 Sep 2011 15:19:20 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1316022536497-3336592.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
	<1315967482773-3334622.post@n3.nabble.com>
	<4E709774.6080203@freyther.de>
	<1316012118966-3336070.post@n3.nabble.com>
	<4E70C1EA.9030308@freyther.de>
	<1316022536497-3336592.post@n3.nabble.com>
Message-ID: <1316038760972-3337347.post@n3.nabble.com>

Hi Rola,

probably you should post the output you are getting from mobile and explain
what you are doing, then it will be clearer what you miss to get things
work.

Cheers,
Loretta

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3337347.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From roladunjoye at gmail.com  Fri Sep 16 01:08:45 2011
From: roladunjoye at gmail.com (rola)
Date: Thu, 15 Sep 2011 18:08:45 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1316038760972-3337347.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
	<1315967482773-3334622.post@n3.nabble.com>
	<4E709774.6080203@freyther.de>
	<1316012118966-3336070.post@n3.nabble.com>
	<4E70C1EA.9030308@freyther.de>
	<1316022536497-3336592.post@n3.nabble.com>
	<1316038760972-3337347.post@n3.nabble.com>
Message-ID: <1316135325373-3340651.post@n3.nabble.com>

Hi All,

Currently I have the Osmocon running layer1.compalram.bin using Motorola
C155.

Mobile runs as ./mobile -i 127.0.0.1. I followed the normal procedure as
followed:

i. Start the osmocon program

ii. Start Mobile App

iii. Turn C155 on

iv. Start Wireshark (Direct Path Source : Git ) with the following
parameters:



Osmocon and Mobile keeps cycling in a loop searching for possible PLMN and
perhaps trying to find a suitable
cell to camp on. After power measure with an average level of -95dB, FCCH
RecognitionL1CTL_RESET_REQ kicks in.
The layer1 process keeps in this loop continuously. Likewise the Mobile app
with gsm322 message of channel
sync error. My guess is Layer1 couldn't found a suitable frequency to sync
with. And I wonder why?

I'll like to know if anyone has successfully run Mobile without SIM using
the Master copy. 

Please, I'll appreciate any hint on what to do from anyone
Thanks.


Osmocon Output:

.
.
.
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FSB_REQ (arfcn=102,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=124
PM MEAS: ARFCN=0, 42 dBm at baseband, -95 dBm at RF
.
.
.
.
.
L1CTL_PM_REQ starts=512 end=885
   
.
.
.
.

<0003> gsm322.c:2268 1 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=1001
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:521 ARFCN  |MCC    |MNC    |LAC    |cell ID|forb.LA|prio  
|min-db |max-pwr|rx-lev
<0003> gsm322.c:521
-------+-------+-------+-------+-------+-------+-------+-------+-------+-------
<0003> gsm322.c:521 
<0003> gsm322.c:2124 Cell search finished without result.
<0003> gsm322.c:823 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3804 (ms 1) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN
selection in state 'A6 no SIM inserted'
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_NO_CELL_FOUND' for Cell selection
in state 'C0 null'
<0003> gsm322.c:823 new state 'C0 null' -> 'C6 any cell selection'
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (0..0)
<0005> gsm48_mm.c:4196 (ms 1) Received 'MM_EVENT_NO_CELL_FOUND' event in
state MM IDLE, no cell available
<0005> gsm48_mm.c:4209 Message unhandled at this state.
<0003> gsm322.c:2900 Found signal (ARFCN 0 rxlev -98 (12))
<0003> gsm322.c:2888 Getting PM for ARFCN 0 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2900 Found signal (ARFCN 0 rxlev -98 (12))
<0003> gsm322.c:2900 Found signal (ARFCN 1 rxlev -95 (15))
<0003> gsm322.c:2900 Found signal (ARFCN 2 rxlev -95 (15))
<0003> gsm322.c:2900 Found signal (ARFCN 3 rxlev -95 (15))
<0003> gsm322.c:2900 Found signal (ARFCN 4 rxlev -98 (12))
<0003> gsm322.c:2900 Found signal (ARFCN 5 rxlev -98 (12))
<0003> gsm322.c:2900 Found signal (ARFCN 6 rxlev -98 (12))
<0003> gsm322.c:2900 Found signal (ARFCN 7 rxlev -97 (13))
<0003> gsm322.c:2900 Found signal (ARFCN 8 rxlev -95 (15))
<0003> gsm322.c:2900 Found signal (ARFCN 9 rxlev -95 (15))
<0003> gsm322.c:2900 Found signal (ARFCN 10 rxlev -95 (15))
<0003> gsm322.c:2900 Found signal (ARFCN 11 rxlev -98 (12))


Mobile Telnet 

rola at ubuntu:~$ telnet localhost 4247
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome to the OsmocomBB control interface
OsmocomBB> en
OsmocomBB# conf t
OsmocomBB(config)# ms 1
OsmocomBB(ms)#no shutdown
OsmocomBB(ms)#en
OsmocomBB# sh ms
MS '1' is up, service is unavailable
  IMEI: 000000000000000
     IMEISV: 0000000000000000
     IMEI generation: fixed
  automatic network selection state: A6 no SIM inserted
  cell selection state: C6 any cell selection
  radio ressource layer state: idle
  mobility management layer state: MM idle, no cell available

OsmocomBB# write
Configuration saved to /home/rola/.osmocom/bb/mobile.cfg
OsmocomBB# 


Rasak



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3340651.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From karnatinagesh at gmail.com  Fri Sep 16 10:47:24 2011
From: karnatinagesh at gmail.com (karnatinagesh at gmail.com)
Date: Fri, 16 Sep 2011 03:47:24 -0700 (PDT)
Subject: Comprehensive User Directive Manual Needed
In-Reply-To: <1316135325373-3340651.post@n3.nabble.com>
References: <1315882855532-3331557.post@n3.nabble.com>
	<1315967482773-3334622.post@n3.nabble.com>
	<4E709774.6080203@freyther.de>
	<1316012118966-3336070.post@n3.nabble.com>
	<4E70C1EA.9030308@freyther.de>
	<1316022536497-3336592.post@n3.nabble.com>
	<1316038760972-3337347.post@n3.nabble.com>
	<1316135325373-3340651.post@n3.nabble.com>
Message-ID: <1316170044239-3341578.post@n3.nabble.com>

Hi All,

i am also stuck at the same point as mentioned by Rasak.
i am also getting the same logs. if any one could tell how to fix it it
would be helpfull.

regards,
nageswara reddy.

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Comprehensive-User-Directive-Manual-Needed-tp3331557p3341578.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From karnatinagesh at gmail.com  Tue Sep 13 07:39:21 2011
From: karnatinagesh at gmail.com (karnatinagesh at gmail.com)
Date: Tue, 13 Sep 2011 00:39:21 -0700 (PDT)
Subject: Not able to download the sources from git clone
	git://git.osmocom.org/osmocom-bb.git
Message-ID: <1315899561902-3331951.post@n3.nabble.com>

Hi,

currently i am not able to download the sources from the git repository.

git clone git://git.osmocom.org/osmocom-bb.git

is there some issues with the git repository ?.


regards,
nageswara reddy.

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Not-able-to-download-the-sources-from-git-clone-git-git-osmocom-org-osmocom-bb-git-tp3331951p3331951.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From 246tnt at gmail.com  Tue Sep 13 07:46:40 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 13 Sep 2011 09:46:40 +0200
Subject: Not able to download the sources from git clone
	git://git.osmocom.org/osmocom-bb.git
In-Reply-To: <1315899561902-3331951.post@n3.nabble.com>
References: <1315899561902-3331951.post@n3.nabble.com>
Message-ID: <CAHL+j0_ZKfcnxdXfhQxQ60f4-=M8-jm3h0qhavRm5Nb3WqyFiw@mail.gmail.com>

> currently i am not able to download the sources from the git repository.
>
> git clone git://git.osmocom.org/osmocom-bb.git
>
> is there some issues with the git repository ?.

Do you by any chance have IPv6 connectivity ?

Seems the IPV6 is not responding right now. Try disabling ipv6 during the clone.

Cheers,

    Sylvain



From 246tnt at gmail.com  Tue Sep 13 07:49:22 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 13 Sep 2011 09:49:22 +0200
Subject: Not able to download the sources from git clone
	git://git.osmocom.org/osmocom-bb.git
In-Reply-To: <CAHL+j0_ZKfcnxdXfhQxQ60f4-=M8-jm3h0qhavRm5Nb3WqyFiw@mail.gmail.com>
References: <1315899561902-3331951.post@n3.nabble.com>
	<CAHL+j0_ZKfcnxdXfhQxQ60f4-=M8-jm3h0qhavRm5Nb3WqyFiw@mail.gmail.com>
Message-ID: <CAHL+j0-Mok-AFS9wN1TeaU5U2i6irpQv84SEXduetEuv_p6kkw@mail.gmail.com>

> Seems the IPV6 is not responding right now. Try disabling ipv6 during the clone.

Disregard that, it's actually my ipv6 uplink that's down.

Sorry for the noise.

Cheers,

    Sylvain



From labadjala6 at gmail.com  Tue Sep 13 12:17:11 2011
From: labadjala6 at gmail.com (labad jala)
Date: Tue, 13 Sep 2011 14:17:11 +0200
Subject: difference between ft232 and max 232?
Message-ID: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>

Hello techies.

Is there a big difference between ft232 and max232? I have taken apart
this cable :
http://www.cellcorner.com/xshp/unlock-phone-codes/motorola-t190-t191-t193-unlock-data-cable.html
and a picture is attached. By the way, the pinout and voltage (+4v)
doesn't seem to match so I'd like to solder it the proper way..Any
advise welcome.

Cheers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMAG0376.jpg
Type: image/jpeg
Size: 2112921 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110913/8c904158/attachment.jpg>

From maciej.grela at gmail.com  Wed Sep 14 15:44:54 2011
From: maciej.grela at gmail.com (Maciej Grela)
Date: Wed, 14 Sep 2011 17:44:54 +0200
Subject: difference between ft232 and max 232?
In-Reply-To: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
References: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
Message-ID: <CABvrX2UypWsCt2ovvvrrejcqoxN8QoDqu7BNTpWsiBWm6YUqEA@mail.gmail.com>

2011/9/13 labad jala <labadjala6 at gmail.com>:
> Hello techies.
>
> Is there a big difference between ft232 and max232?

FT232 is USB <-> RS232 (5Vpp)

MAX232 is RS232 (5Vpp) <-> RS232 (12Vpp)

Best regards,
Maciej Grela



From sebastien at lorquet.fr  Wed Sep 14 16:07:13 2011
From: sebastien at lorquet.fr (Sebastien Lorquet)
Date: Wed, 14 Sep 2011 18:07:13 +0200
Subject: difference between ft232 and max 232?
In-Reply-To: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
References: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
Message-ID: <4E70D131.2040106@lorquet.fr>

Hi,

If you're thinking of the FTDI ft232, then the little difference is that this
chip is an USB-serial bridge, while the MAX232 is just a level translator that
requires a plain old serial port.

BTW, thanks for the gigantically huge attachement; I guess a 2MB , 3264x1952
jpeg is absolutely required to show your max232 cable.

Regards,
Sebastien

Le 13/09/2011 14:17, labad jala a ?crit :
> Hello techies.
>
> Is there a big difference between ft232 and max232? I have taken apart
> this cable :
> http://www.cellcorner.com/xshp/unlock-phone-codes/motorola-t190-t191-t193-unlock-data-cable.html
> and a picture is attached. By the way, the pinout and voltage (+4v)
> doesn't seem to match so I'd like to solder it the proper way..Any
> advise welcome.
>
> Cheers.




From 246tnt at gmail.com  Wed Sep 14 16:13:45 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Sep 2011 18:13:45 +0200
Subject: difference between ft232 and max 232?
In-Reply-To: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
References: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
Message-ID: <CAHL+j08efcVBO21iU7VOBtx8Cwv5feZEjTDxL6n4YnrcV8A1Xg@mail.gmail.com>

> Is there a big difference between ft232 and max232?

They have _nothing_ in common except for the 232 in their name ...

Cheers,

    Sylvain



From screaming-pain at libero.it  Wed Sep 14 22:07:50 2011
From: screaming-pain at libero.it (screaming-pain)
Date: Wed, 14 Sep 2011 15:07:50 -0700 (PDT)
Subject: difference between ft232 and max 232?
In-Reply-To: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
References: <CAPkZCq5RfTc1k+gJTyck1Ntme28kdiAduyaXEHHEwHE4QC4Mfg@mail.gmail.com>
Message-ID: <1316038070841-3337291.post@n3.nabble.com>

Eheheheh
I did the same when I was frustrated because the cable I bought from
cellcorner wasn't working!
Not that I had any hope to fix it or understand it :((
However, as I have already said the problem was the jack not fitting
properly in, if you have the same problem, just cut off a bit of plastic,
now it's my favourite cable ;))

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/difference-between-ft232-and-max-232-tp3336220p3337291.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From izsh at fail0verflow.com  Thu Sep 15 16:25:50 2011
From: izsh at fail0verflow.com (iZsh)
Date: Thu, 15 Sep 2011 18:25:50 +0200
Subject: Patch suggestion for wireshark's LAPDm dissector
Message-ID: <96834F08-DF29-4842-984A-E3DA12ECFBA8@fail0verflow.com>

Hello,

(my first post to this ML)

Sylvain told me it might be a good place to post this.

Please find attached a small patch for wireshark's LAPDm dissector.
It currently fails at reassembling LAPDm packets when processing multiple streams at the same time insofar as it always assume the fragmented type I LAPDm frames belong to the same stream. This is of course wrong if you process, for instance, all the timeslots of a S{D,A}CCH channel.

The proposed patch, which might not be ideal but seems to work better with my testcase (and not worse), identifies the stream using the tuple (link direction, timeslot, subslot). I reused the packet_info's circuit_id field for this, which should be safe enough to use.

Let me know if you have any comments., hopefully this could be committed upstream by someone with commit access.

Best Regards,
iZsh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lapdm_fragmentation.patch
Type: application/octet-stream
Size: 1746 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110915/236e6dc9/attachment.obj>

From torfun at web.de  Thu Sep 15 18:01:55 2011
From: torfun at web.de (Tobias Funke)
Date: Thu, 15 Sep 2011 20:01:55 +0200
Subject: Failed to initialize flash! Why?
Message-ID: <CAA-gtZSnKgpGfr8vS6PGz1QWQ2iTfpiVoufX0qSzdcLS46KzBA@mail.gmail.com>

Hi,

sorry if I shouldn`t write correclly, i'm not that good in english.

i have a Motorola c118 and now aFTDI cable.

my problem:
compiling was successfully.

than i run osmocon:
./osmocon -p /dev/ttyUSB0 -m c123xor
/home/test/install/osmocom-bb/src/target/firmware/board/compal_e88/layer1.ramload.bin

i pressed power button and get this output:

got 2 bytes from modem, data looks like: 04 81  ..
got 5 bytes from modem, data looks like: 1b f6 02 00 41  ....A
got 1 bytes from modem, data looks like: 01  .
got 1 bytes from modem, data looks like: 40  @
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/loader.compalram.bin):
file_size=17184, hdr_len=4, dnload_len=17191
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 43  C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/17191)
handle_write(): 4096 bytes (8192/17191)
handle_write(): 4096 bytes (12288/17191)
handle_write(): 4096 bytes (16384/17191)
handle_write(): 807 bytes (17191/17191)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 03  .
got 1 bytes from modem, data looks like: 42  B
Received DOWNLOAD ACK from phone, your code is running now!
Received DOWNLOAD ACK from phone, your code is running now!


OSMOCOM Loader (revision osmocon_v0.0.0-1108-g7bbd2ac)
======================================================================
Running on compal_e88 in environment compalram
Failed to initialize flash!

_____________________
Why initializing flash failed?

what is my fault? can you help me?

thanks a lot,
tobsen



From torfun at web.de  Fri Sep 16 20:14:32 2011
From: torfun at web.de (tobsen)
Date: Fri, 16 Sep 2011 13:14:32 -0700 (PDT)
Subject: Failed to initialize flash! Why?
In-Reply-To: <CAA-gtZSnKgpGfr8vS6PGz1QWQ2iTfpiVoufX0qSzdcLS46KzBA@mail.gmail.com>
References: <CAA-gtZSnKgpGfr8vS6PGz1QWQ2iTfpiVoufX0qSzdcLS46KzBA@mail.gmail.com>
Message-ID: <1316204072629-3342931.post@n3.nabble.com>

hi,

I was looking at older mail on the  mailing list, so I found this:
_______________________________________________________________
 > When I run  the loader with "osmcon --m c123xor" the loader starts but
 > says "Failed to initialize flash".

[...]
Did you use the flash unlock command first, before trying to write to it? 
_______________________________________________________________

i think thats the answer to my question... 
did anybody now, what i must do to unlock my phone's flash? or perhaps a
link?

tobsen

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Failed-to-initialize-flash-Why-tp3339785p3342931.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From steve at steve-m.de  Fri Sep 16 22:16:58 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Sat, 17 Sep 2011 00:16:58 +0200
Subject: Failed to initialize flash! Why?
In-Reply-To: <1316204072629-3342931.post@n3.nabble.com>
References: <CAA-gtZSnKgpGfr8vS6PGz1QWQ2iTfpiVoufX0qSzdcLS46KzBA@mail.gmail.com>
	<1316204072629-3342931.post@n3.nabble.com>
Message-ID: <4E73CADA.7030900@steve-m.de>

Hi,

On 16.09.2011 22:14, tobsen wrote:

> i think thats the answer to my question... 
> did anybody now, what i must do to unlock my phone's flash? or perhaps a
> link?

What do you want to achieve anyway? Flashing is absolutely not needed
for using the phone with osmocom-bb and still highly experimental, in
fact, the only person I'm aware of that successfully flashed a phone
so far is prom, but only for playing with the bootloader.

For normal operation just use osmocon with layer1.bin.
It will upload the layer1-binary in the internal SRAM of the phone and
run it from there, and you're just fine with that.

Regards,
Steve



From 246tnt at gmail.com  Fri Sep 16 21:10:14 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 16 Sep 2011 23:10:14 +0200
Subject: RFC: libosmocore generic CRC
Message-ID: <CAHL+j0-Zh7Z-HwWqHZDaEjZsxHS9myJ-Dy2bJZZEfduK9TrJBQ@mail.gmail.com>

Hi,

I've just pused in libosmocore a branch sylvain/crc with a proposal
for some generic CRC function.

The goal here is to provide a base implementation so that channel
coding/decoding of the various other projects can use this as a base
rather than reimplement their own for each poly. The API is targeted
towards that use (using array of ubit_t rather than a buffer of packed
bits).

The code is generated from a template and expanded into a 8 / 16 / 32
/ 64 bits version by the Makefile (each capable of supporting any crc
length inferior or equal to that. So a CRC12 would use the 16bits
state function).

Appropriate doxygen doc is included.

If nobody has objection / comments / ... I'll go ahead and merge it.

Cheers,

    Sylvain



From laforge at gnumonks.org  Sat Sep 17 04:41:37 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 17 Sep 2011 05:41:37 +0100
Subject: RFC: libosmocore generic CRC
In-Reply-To: <CAHL+j0-Zh7Z-HwWqHZDaEjZsxHS9myJ-Dy2bJZZEfduK9TrJBQ@mail.gmail.com>
References: <CAHL+j0-Zh7Z-HwWqHZDaEjZsxHS9myJ-Dy2bJZZEfduK9TrJBQ@mail.gmail.com>
Message-ID: <20110917044137.GU12544@prithivi.gnumonks.org>

Hi Sylvain,

On Fri, Sep 16, 2011 at 11:10:14PM +0200, Sylvain Munaut wrote:
> 
> If nobody has objection / comments / ... I'll go ahead and merge it.

looks fine to me, definitely no objections.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From nghia.phan31 at gmail.com  Sun Sep 18 08:14:24 2011
From: nghia.phan31 at gmail.com (nghia phan)
Date: Sun, 18 Sep 2011 10:14:24 +0200
Subject: Architecture of oscomBB
Message-ID: <CACr51FTUcsA_q7oa-9OOMnh7a6AkdOR75jg2tdAYQq9Xkn83XA@mail.gmail.com>

Hello everyone,

I'm new to OscomBB and have few questions about its architecture. I have
ordered the C123 and the serial cable. Note: I have OpenBTS running quite
well and would like now to explore the other end.

I did look at the Software Overview page and have the following questions:
a/ where can I log the raw burst (156 bits)? [ not the IQ samples ] on the
PC? on the ARM7?
b/ on the downllink path, how is the FCH detection process split between
dsp, arm7 and PC? ie from raw burst to FCH detection indication and offset
value.
c/ on the downllink path, how is the SCH decode process split between dsp,
arm7 and PC? ie from raw burst to GSM frame number, BSIC etc..
d/ on the downllink path, how is the BCCH decode process split between dsp,
arm7 and PC? ie from raw burst to System Informations...
d/ on the uplink path, how the RACH encode process (RACH_REQ) is split
between dsp, arm7 and PC?

Thank your for your kind answers.

Rgds
Nghia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110918/4146674f/attachment.htm>

From laforge at gnumonks.org  Sun Sep 18 10:11:31 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 18 Sep 2011 12:11:31 +0200
Subject: Architecture of oscomBB
In-Reply-To: <CACr51FTUcsA_q7oa-9OOMnh7a6AkdOR75jg2tdAYQq9Xkn83XA@mail.gmail.com>
References: <CACr51FTUcsA_q7oa-9OOMnh7a6AkdOR75jg2tdAYQq9Xkn83XA@mail.gmail.com>
Message-ID: <20110918101131.GF19221@prithivi.gnumonks.org>

Hi,

On Sun, Sep 18, 2011 at 10:14:24AM +0200, nghia phan wrote:

> b/ on the downllink path, how is the FCH detection process split between
> dsp, arm7 and PC? ie from raw burst to FCH detection indication and offset
> value.
> c/ on the downllink path, how is the SCH decode process split between dsp,
> arm7 and PC? ie from raw burst to GSM frame number, BSIC etc..
> d/ on the downllink path, how is the BCCH decode process split between dsp,
> arm7 and PC? ie from raw burst to System Informations...
> d/ on the uplink path, how the RACH encode process (RACH_REQ) is split
> between dsp, arm7 and PC?

It's the same for all of them: 

* demodulation, interleaving, convolutional code, etc. is all in the DSP
* scheduling (TDMA frame/multiframe/etc) as well as frequency and tx
  power control is done by the ARM
* the interface between layer1 and layer2 (LAPDm) is via serial line
  and everything L2 or higher runs on the PC.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From roladunjoye at gmail.com  Tue Sep 20 02:00:11 2011
From: roladunjoye at gmail.com (rola)
Date: Mon, 19 Sep 2011 19:00:11 -0700 (PDT)
Subject: GSM 850 / PCS 1900 : PLEASE HELP NEEDED
Message-ID: <1316484011408-3350771.post@n3.nabble.com>

Hi All,

I have done all what I could in setting up the project and running of it as
indicated in the wiki and mailing list.
It has been over two weeks of trial and error of figuring out of what the
problem is that led me to this conclusion
that OsmocomBB project might not be designed optimally for US GSM Bands (GSM
850/ PCS 1900). The system
could not get synchronised to a frequency when FSBS request is carried out.

I read  from the mailing-list about the possible modification to be done on
the file rffe_dualband.c for GSM band in US in order to resolve the issue of
synchronisation. I made a changed of DCS 1800 to PCS 1900 and yet the output
remain the same with no difference.

Perhaps, I am still overlooking a possible detail that might make the MS not
synchronising. However the power measure is of average -90dBm which I think
might be too low for required level. If there can be anyone with any clue to
resolve or shed more light on this issue I am kindly requesting for
assistance

I have my configuration and output as followed:

 SYSTEM CONFIGURATION:

 OS : Ubuntu 10.10 Maverick Meerkat
 TI- Calypso: Motorola C155 (US Model)
 Cable: PL2303 USB cable
 Tool-chain: Self compiled GNUArm tool-chain based on instruction on
http://bb.osmocom.org/trac/wiki/GnuArmToolchain
OsmocomBB Branch: Successful installation of both Master and Sylvain branch
with modification to Makefile to enable      transmitting


PROGRAM OUTPUTS:

Running OsmocomBB (Sylvain Branch)

Osmocon Output 1 :

rola at amira:~/test2-osmocom-bb/osmocom-bb/src/host/osmocon$ ./osmocon -p
/dev/ttyUSB0 -m c155
../../target/firmware/board/compal_e99/layer1.compalram.bin
got 1 bytes from modem, data looks like: 00  .
got 6 bytes from modem, data looks like: 1b f6 02 00 41 01  ....A.
got 1 bytes from modem, data looks like: 40  @
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e99/layer1.compalram.bin):
file_size=53804, hdr_len=4, dnload_len=53811
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 43  C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/53811)
handle_write(): 4096 bytes (8192/53811)
handle_write(): 4096 bytes (12288/53811)
handle_write(): 4096 bytes (16384/53811)
handle_write(): 4096 bytes (20480/53811)
handle_write(): 4096 bytes (24576/53811)
handle_write(): 4096 bytes (28672/53811)
handle_write(): 4096 bytes (32768/53811)
handle_write(): 4096 bytes (36864/53811)
handle_write(): 4096 bytes (40960/53811)
handle_write(): 4096 bytes (45056/53811)
handle_write(): 4096 bytes (49152/53811)
handle_write(): 4096 bytes (53248/53811)
handle_write(): 563 bytes (53811/53811)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 03  .
got 1 bytes from modem, data looks like: 42  B
Received DOWNLOAD ACK from phone, your code is running now!


OSMOCOM Layer 1 (revision osmocon_v0.0.0-1111-ge838620)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: 7e570d2eb10393bb
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
Power up simcard:
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 3907!
LOST 3750!

Above output was done with Mobile App not in used.


Running Osmocon with Mobile App.

Mobile App Output 1:

rola at amira:~$ cd test2-osmocom-bb/osmocom-bb/src/host/layer23/src/mobile/
rola at amira:~/test2-osmocom-bb/osmocom-bb/src/host/layer23/src/mobile$
./mobile -i 127.0.0.1
Copyright (C) 2008-2010 ...
Contributions by ...

License GPLv2+: GNU GPL version 2 or later
&lt;http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000f> sim.c:1206 init SIM client
<0006> gsm48_cc.c:63 init Call Control
<0001> gsm48_rr.c:5100 init Radio Ressource process
<0005> gsm48_mm.c:1312 init Mobility Management process
<0005> gsm48_mm.c:1035 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:5023 init PLMN process
<0003> gsm322.c:5024 init Cell Selection process
***
Warning: Mobile '1' has default IMEI: 000000000000000
This could relate your identitiy to other users with default IMEI.
***
Mobile '1' initialized, please start phone now!
VTY available on port 4247.
<0005> subscriber.c:567 Requesting SIM file 0x2fe2
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:697 go MF
<000f> sim.c:241 SELECT (file=0x3f00)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)

******The above output runs with MS still turned off.


Telnet Output:

rola at amira:~$ telnet localhost 4247
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome to the OsmocomBB control interface
OsmocomBB> en
OsmocomBB# sim read 1
OsmocomBB# conf t
OsmocomBB(config)# ms 1
OsmocomBB(ms)#noshutdown
% Unknown command.
OsmocomBB(ms)#
% (MS 1)
% No service.


OsmocomBB(ms)#en
OsmocomBB# sh ms
MS '1' is up, service is unavailable
  IMEI: 000000000000000
     IMEISV: 0000000000000000
     IMEI generation: fixed
  automatic network selection state: A4 wait for PLMN to appear
  cell selection state: C6 any cell selection
  radio ressource layer state: idle
  mobility management layer state: MM idle, no cell available

OsmocomBB# sh support
Supported features of MS '1':
 Phase 2 mobile station
 R-GSM        : yes
 E-GSM        : yes
 P-GSM        : yes
 GSM900 Class : 4
 DCS 1800     : yes
 DCS Class    : 1
 GSM 850      : disabled
 PCS 1900     : disabled
 GSM 480      : no
 GSM 450      : no
 CECS         : no
 VGCS         : no
 VBS          : no
 SMS          : no
 SS_IND       : yes
 PS_CAP       : no
 CMSP         : no
 SoLSA        : no
 LCSVA        : no
 LOC_SERV     : no
 A5/1         : yes
 A5/2         : yes
 A5/3         : no
 A5/4         : no
 A5/5         : no
 A5/6         : no
 A5/7         : no
 A5/1         : yes
 Channels     : SDCCH + TCH/F + TCH/H
 Full-Rate V1 : yes
 Full-Rate V2 : yes
 Full-Rate V3 : no
 Half-Rate V1 : yes
 Half-Rate V3 : no
 Min RXLEV    : -106

OsmocomBB# 

**** Clearly above under supporrt command, PCS 1900 and GSM 850 is disabled.
I have no clue of how turn it on.

Osmocon Output 2:

PM MEAS: ARFCN=120, 35   dBm at baseband, -102 dBm at RF
PM MEAS: ARFCN=121, 41   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=122, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=123, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=124, 41   dBm at baseband, -97  dBm at RF
L1CTL_PM_REQ start=512 end=885
PM MEAS: ARFCN=512, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=512, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=513, 40   dBm at baseband, -97  dBm at RF
-
-
-
PM MEAS: ARFCN=883, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=884, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=885, 44   dBm at baseband, -94  dBm at RF
L1CTL_PM_REQ start=955 end=1023
PM MEAS: ARFCN=955, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=955, 37   dBm at baseband, -101 dBm at RF
-

-

-

PM MEAS: ARFCN=1021, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=1022, 36   dBm at baseband, -101 dBm at RF
PM MEAS: ARFCN=1023, 41   dBm at baseband, -96  dBm at RF
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=872, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=1002,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=1000,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=983,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=979,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=966,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=962,
flags=0x7)
Starting FCCH RecognitionLOST 1885!
LOST 1865!
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=958, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=957,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=879,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=877,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=876,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=874,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=871,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=867,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=849,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=844,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=839,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=837,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=835,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=828,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=827,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=826,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=824,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=820,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=818,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=817,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=811,
flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=809,
flags=0x7)
^C
rola at amira:~/test2-osmocom-bb/osmocom-bb/src/host/osmocon$ 

**** The FBSB yield no result


Mobile App Output2:

<0003> gsm322.c:2900 Found signal (ARFCN 648(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 649(DCS) rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 650(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 651(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 652(DCS) rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 653(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 654(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 655(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 656(DCS) rxlev -94 (16))

-

-
--
-
<0003> gsm322.c:2900 Found signal (ARFCN 876(DCS) rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 877(DCS) rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 878(DCS) rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 879(DCS) rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 880(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 881(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 882(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 883(DCS) rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 884(DCS) rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 885(DCS) rxlev -94 (16))
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2851 Scanning frequencies. (955..955)
<0003> gsm322.c:2900 Found signal (ARFCN 955 rxlev -96 (14))
<0003> gsm322.c:2888 Getting PM for ARFCN 955 twice. Overwriting the first!
Please fix prim_pm.c
<0003> gsm322.c:2900 Found signal (ARFCN 955 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 956 rxlev -100 (10))
<0003> gsm322.c:2900 Found signal (ARFCN 957 rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 958 rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 959 rxlev -96 (14))
--
--
--
--


<0003> gsm322.c:2900 Found signal (ARFCN 998 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 999 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1000 rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 1001 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1002 rxlev -93 (17))
<0003> gsm322.c:2900 Found signal (ARFCN 1003 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1004 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1005 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1006 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1007 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1008 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1009 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1010 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1011 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1012 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1013 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1014 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1015 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1016 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1017 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1018 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1019 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1020 rxlev -96 (14))
<0003> gsm322.c:2900 Found signal (ARFCN 1021 rxlev -94 (16))
<0003> gsm322.c:2900 Found signal (ARFCN 1022 rxlev -101 (9))
<0003> gsm322.c:2900 Found signal (ARFCN 1023 rxlev -96 (14))
<0003> gsm322.c:2912 Done with power scanning range.
<0003> gsm322.c:2790 Scanning power for all frequencies.
<0003> gsm322.c:2828 Found 568 frequencies.
<0003> gsm322.c:2248 Scanning frequency 872(DCS) (rxlev -92).
<0003> gsm322.c:469 Sync to ARFCN=872(DCS) rxlev=-92 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 40 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=872(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 1002 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=1002 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 30 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=1002
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 1000 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=1000 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 29 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=1000
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 983 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=983 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 28 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=983
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 979 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=979 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 27 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=979
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 966 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=966 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 26 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=966
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 962 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=962 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 25 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=962
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 958 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=958 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 24 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=958
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 957 (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=957 rxlev=-93 (No sysinfo yet, ccch mode
NONE)
<0003> gsm322.c:2268 23 frequencies left in band 955..124
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=957
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 879(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=879(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 39 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=879(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 877(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=877(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 38 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=877(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 876(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=876(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 37 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=876(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 874(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=874(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 36 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=874(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 871(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=871(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 35 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=871(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 867(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=867(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 34 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=867(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 849(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=849(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 33 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=849(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 844(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=844(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 32 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=844(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 839(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=839(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 31 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=839(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 837(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=837(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 30 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=837(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 835(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=835(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 29 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=835(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 828(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=828(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 28 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
--
--
--


<0003> gsm322.c:2268 23 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=818(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 817(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=817(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 22 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=817(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 811(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=811(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 21 frequencies left in band 512..885
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=811(DCS)
<0003> gsm322.c:2734 Cell selection failed, sync timeout.
<0003> gsm322.c:2248 Scanning frequency 809(DCS) (rxlev -93).
<0003> gsm322.c:469 Sync to ARFCN=809(DCS) rxlev=-93 (No sysinfo yet, ccch
mode NONE)
<0003> gsm322.c:2268 20 frequencies left in band 512..885

**** The output displayed cell selection failure. The process repeats itself
continuously 

Thanks

Rasak











--
View this message in context: http://baseband-devel.722152.n3.nabble.com/GSM-850-PCS-1900-PLEASE-HELP-NEEDED-tp3350771p3350771.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From 246tnt at gmail.com  Tue Sep 20 06:05:01 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 20 Sep 2011 08:05:01 +0200
Subject: GSM 850 / PCS 1900 : PLEASE HELP NEEDED
In-Reply-To: <1316484011408-3350771.post@n3.nabble.com>
References: <1316484011408-3350771.post@n3.nabble.com>
Message-ID: <CAHL+j0_yfHNH8MHLq-4N-m3PN6c5GTqk=AUnzzqSWa7GxHijtw@mail.gmail.com>

> that OsmocomBB project might not be designed optimally for US GSM Bands (GSM
> 850/ PCS 1900). The system
> could not get synchronised to a frequency when FSBS request is carried out.

Well you need to enable it in the configuration for it to even try those bands.

In the telnet vty interface try something like

enable
conf t
ms 1
support
gsm-850
pcs
write


Cheers,

    Sylvain



From roladunjoye at gmail.com  Wed Sep 21 01:26:35 2011
From: roladunjoye at gmail.com (rola)
Date: Tue, 20 Sep 2011 18:26:35 -0700 (PDT)
Subject: GSM 850 / PCS 1900 : PLEASE HELP NEEDED
In-Reply-To: <1316484011408-3350771.post@n3.nabble.com>
References: <1316484011408-3350771.post@n3.nabble.com>
Message-ID: <1316568395955-3354030.post@n3.nabble.com>

Hi All,

Thanks a lot Sylvain for your response. At least the SIM Reader  can read
the SIM information now. The Mobile outputs the following: IMEI, IMSI,
ICCID, MCC, MNC,LAC and the KEY. But, the process returnes failure for SIM
file at 0x6f40 and hangs while retrieving information for SIM file at to
retrieve information in location 0x6f30. However, after making sure that the
gsm-850 and pcs are enabled, running of the Osmocon without SIM still yield
the same output I posted earlier with DCS as the reference band of the
Mobile output.

Running Osmocon with SIM:

Osmocom Output:


rola at amira:~/test2-osmocom-bb/osmocom-bb/src/host/osmocon$ ./osmocon -p
/dev/ttyUSB0 -m c155
../../target/firmware/board/compal_e99/layer1.compalram.bin
got 7 bytes from modem, data looks like: 1b f6 02 00 41 01 40  ....A.@
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e99/layer1.compalram.bin):
file_size=53804, hdr_len=4, dnload_len=53811
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 43  C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/53811)
handle_write(): 4096 bytes (8192/53811)
handle_write(): 4096 bytes (12288/53811)
handle_write(): 4096 bytes (16384/53811)
handle_write(): 4096 bytes (20480/53811)
handle_write(): 4096 bytes (24576/53811)
handle_write(): 4096 bytes (28672/53811)
handle_write(): 4096 bytes (32768/53811)
handle_write(): 4096 bytes (36864/53811)
handle_write(): 4096 bytes (40960/53811)
handle_write(): 4096 bytes (45056/53811)
handle_write(): 4096 bytes (49152/53811)
handle_write(): 4096 bytes (53248/53811)
handle_write(): 563 bytes (53811/53811)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 03  .
got 1 bytes from modem, data looks like: 42  B
Received DOWNLOAD ACK from phone, your code is running now!


OSMOCOM Layer 1 (revision osmocon_v0.0.0-1111-ge838620)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: 7e570d2eb10393bb
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
Power up simcard:
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 7019!
SIM Request (7): a0 a4 00 00 02 3f 00 
Status 2: 9F 22
SIM Request (5): a0 c0 00 00 22 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 2f e2 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (5): a0 b0 00 00 0a 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 7f 20 
Status 2: 9F 22
SIM Request (5): a0 c0 00 00 22 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 07 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (5): a0 b0 00 00 09 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 7e 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (5): a0 b0 00 00 0b 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 3f 00 
Status 2: 9F 22
SIM Request (5): a0 c0 00 00 22 
Status 1: 90 00
LOST 1893!
LOST 1857!
SIM Request (7): a0 a4 00 00 02 7f 10 
Status 2: 9F 22
SIM Request (5): a0 c0 00 00 22 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 40 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (5): a0 b0 00 00 80 
Status 1: 94 08
SIM Request (7): a0 a4 00 00 02 3f 00 
Status 2: 9F 22
SIM Request (5): a0 c0 00 00 22 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 7f 20 
Status 2: 9F 22
SIM Request (5): a0 c0 00 00 22 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 20 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (5): a0 b0 00 00 09 
Status 1: 90 00
SIM Request (7): a0 a4 00 00 02 6f 30 
Status 2: 9F 0F
SIM Request (5): a0 c0 00 00 0f 
Status 1: 90 00
SIM Request (5): a0 b0 00 00 fc 

Osmocon hang at this point.

Mobile Output:



rola at amira:~/test2-osmocom-bb/osmocom-bb/src/host/layer23/src/mobile$
./mobile -i 127.0.0.1
Copyright (C) 2008-2010 ...
Contributions by ...

License GPLv2+: GNU GPL version 2 or later
&lt;http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000f> sim.c:1206 init SIM client
<0006> gsm48_cc.c:63 init Call Control
<0001> gsm48_rr.c:5100 init Radio Ressource process
<0005> gsm48_mm.c:1312 init Mobility Management process
<0005> gsm48_mm.c:1035 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:5023 init PLMN process
<0003> gsm322.c:5024 init Cell Selection process
***
Warning: Mobile '1' has default IMEI: 000000000000000
This could relate your identitiy to other users with default IMEI.
***
Mobile '1' initialized, please start phone now!
VTY available on port 4247.
<0005> subscriber.c:567 Requesting SIM file 0x2fe2
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:697 go MF
<000f> sim.c:241 SELECT (file=0x3f00)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x22)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=34)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=34 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:241 SELECT (file=0x2fe2)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:277 READ BINARY (offset=0 len=10)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
<000f> sim.c:876 received APDU (len=10 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:151 sending result to callback function (type=0)
<0005> subscriber.c:236 received ICCID #################### from SIM
<0005> subscriber.c:567 Requesting SIM file 0x6f07
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:706 requested path is longer, go child DFgsm
<000f> sim.c:241 SELECT (file=0x7f20)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x22)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=34)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=34 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:241 SELECT (file=0x6f07)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:277 READ BINARY (offset=0 len=9)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
<000f> sim.c:876 received APDU (len=9 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:151 sending result to callback function (type=0)
<0005> subscriber.c:266 received IMSI ################ from SIM
<0005> subscriber.c:567 Requesting SIM file 0x6f7e
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:241 SELECT (file=0x6f7e)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:277 READ BINARY (offset=0 len=11)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
<000f> sim.c:876 received APDU (len=11 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:151 sending result to callback function (type=0)
<0005> subscriber.c:302 received LOCI from SIM (mcc=### mnc=### lac=#####
##)
<0005> subscriber.c:567 Requesting SIM file 0x6f40
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:697 go MF
<000f> sim.c:241 SELECT (file=0x3f00)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x22)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=34)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=34 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:706 requested path is longer, go child DFtelecom
<000f> sim.c:241 SELECT (file=0x7f10)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x22)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=34)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=34 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:241 SELECT (file=0x6f40)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:277 READ BINARY (offset=0 len=128)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
<000f> sim.c:876 received APDU (len=128 sw1=0x94 sw2=0x08)
<000f> sim.c:952 command failed
<000f> sim.c:151 sending result to callback function (type=1)
<0005> subscriber.c:620 SIM reading failed, ignoring!
<0005> subscriber.c:567 Requesting SIM file 0x6f20
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:697 go MF
<000f> sim.c:241 SELECT (file=0x3f00)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x22)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=34)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=34 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:706 requested path is longer, go child DFgsm
<000f> sim.c:241 SELECT (file=0x7f20)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x22)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=34)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=34 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:241 SELECT (file=0x6f20)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:277 READ BINARY (offset=0 len=9)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
<000f> sim.c:876 received APDU (len=9 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:151 sending result to callback function (type=0)
<0005> subscriber.c:349 received KEY from SIM
<0005> subscriber.c:567 Requesting SIM file 0x6f30
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:241 SELECT (file=0x6f30)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:277 READ BINARY (offset=0 len=252)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)

###### are place holders for actual SIM information.

 Telnett Output:
OsmocomBB# show running-config

Current configuration:
!
!
line vty
 no login
!
gps device /dev/ttyACM0
gps baudrate default
no gps enable
!
no hide-default
!
ms 1
 layer2-socket /tmp/osmocom_l2
 sap-socket /tmp/osmocom_sap
 sim reader
 network-selection-mode auto
 imei 000000000000000 0
 imei-fixed
 no emergency-imsi
 no call-waiting
 no auto-answer
 no clip
 no clir
 tx-power auto
 no simulated-delay
 no stick
 location-updating
 neighbour-measurement
 codec full-speed prefer
 codec half-speed
 no abbrev
 support
  a5/1
  a5/2
  no p-gsm
  no e-gsm
  no r-gsm
  gsm-850
  no dcs
  pcs
  class-900 4
  class-850 4
  class-dcs 1
  class-pcs 1
  channel-capability sdcch+tchf+tchh
  full-speech-v1
  full-speech-v2
  half-speech-v1
  min-rxlev -106
  dsc-max 90
  no skip-max-per-band
 exit
 test-sim
  imsi 001010000000000
  ki xor 00 00 00 00 00 00 00 00 00 00 00 00 
  no barred-access
  no rplmn
  hplmn-search foreign-country
 exit
 no shutdown
exit
!
end
OsmocomBB# sim read 1
OsmocomBB# show ms 1
MS '1' is up, service is limited
  IMEI: 000000000000000
     IMEISV: 0000000000000000
     IMEI generation: fixed
  automatic network selection state: A6 no SIM inserted
  cell selection state: C6 any cell selection
  radio ressource layer state: idle
  mobility management layer state: MM idle, PLMN search
OsmocomBB# show support
Supported features of MS '1':
 Phase 2 mobile station
 R-GSM        : disabled
 E-GSM        : disabled
 P-GSM        : disabled
 DCS 1800     : disabled
 GSM 850      : yes
 GSM 850 Class: 4
 PCS 1900     : yes
 PCS Class    : 1
 GSM 480      : no
 GSM 450      : no
 CECS         : no
 VGCS         : no
 VBS          : no
 SMS          : no
 SS_IND       : yes
 PS_CAP       : no
 CMSP         : no
 SoLSA        : no
 LCSVA        : no
 LOC_SERV     : no
 A5/1         : yes
 A5/2         : yes
 A5/3         : no
 A5/4         : no
 A5/5         : no
 A5/6         : no
 A5/7         : no
 A5/1         : yes
 Channels     : SDCCH + TCH/F + TCH/H
 Full-Rate V1 : yes
 Full-Rate V2 : yes
 Full-Rate V3 : no
 Half-Rate V1 : yes
 Half-Rate V3 : no
 Min RXLEV    : -106

OsmocomBB# 
 I disabled every other band except gsm-850 and pcs.


I have been taken time reading through the source codes and tracking the
process from one section to another. And at the same digging for information
on techniques and protocols applied in the project. I hope I can just get
the application runs to a level where I can use it to establish a call.
Thanks to everyone.

Best regards,

Rasak

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/GSM-850-PCS-1900-PLEASE-HELP-NEEDED-tp3350771p3354030.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From nghia.phan31 at gmail.com  Wed Sep 21 20:44:38 2011
From: nghia.phan31 at gmail.com (nghia phan)
Date: Wed, 21 Sep 2011 22:44:38 +0200
Subject: Issue with Airprobe & USRP1/RFX900/52M
Message-ID: <CACr51FR_044MQy=uZF0V0Dt6SvpxFiUFxnzqcuXrAQ89rt5Duw@mail.gmail.com>

Hello everyone,

I'm looking for help.


I have downloaded and built Airprobe (gsm-receiver, gssm, ) on my Ubuntu
machine.

a/ Using the capture file provided on the web site, I could get a first
level of decoding done:

nphan at ubuntu:~/airprobe/gsm-receiver/src/python$ more capture_941.8M_112.log

Key: '0000000000000000'
Configuration: ''
  No configuration set.
configure_receiver
1670173 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670177 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670183 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670187 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670193 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670197 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670204 0: 01 06 07 60 00 25 54 a8 f9 74 05 5e 18 73 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670208 0: 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670214 0: 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670218 0: 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670224 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670228 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b
1670234 0: 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2b

but in wireshark I can't see any decoded info such as BCCH system info
etc...

b/ It looks like my capture isn't working properly either (ie I can't even
get the 1st level of decoding as with capture file provided in the web
site).

nphan at ubuntu:~/airprobe/gsm-receiver/src/python$ ./capture.sh 953.4M
/usr/local/bin/usrp_rx_cfile.py
Capturing for 10 seconds to capture_953.4M_112.cfile (4642850 samples)
Using RX d'board B: Flex 900 Rx
USB sample rate 571.428k
nphan at ubuntu:~/airprobe/gsm-receiver/src/python$ ./go.sh
capture_953.4M_112.cfile
>>> gr_fir_ccc: using SSE
>>> gr_fir_ccf: using SSE
Key: '0000000000000000'
Configuration: ''
  No configuration set.
configure_receiver
gr_buffer::allocate_buffer: warning: tried to allocate
   115 items of size 568. Due to alignment requirements
   512 were allocated.  If this isn't OK, consider padding
   your structure to a power-of-two bytes.
   On this platform, our allocation granularity is 4096 bytes.
nphan at ubuntu:~/airprobe/gsm-receiver/src/python$


I have a USRP1 with 2 RFX900 with a ClockTamer providing 52Mhz clock.

I have changed the various Python scripts so that the RFX daughter on side B
and RX2  are selected. I have also changed the clock rate to 52M to match my
HW.  I have input the frequency of a known BTS (which kal can see and
measure the offset).

Any hints about what is wrong in my set-up or process?

Thanks
Nghia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110921/53cf6ccc/attachment.htm>

From andre at ac.nl.eu.org  Thu Sep 22 09:24:20 2011
From: andre at ac.nl.eu.org (AndrXX)
Date: Thu, 22 Sep 2011 11:24:20 +0200
Subject: IPv6 connectivity to bb.osmocom.org
Message-ID: <cmu-lmtpd-21843-1316699073-0@ganesha>


Hi All,

Is IPv6 connectivity to  bb.osmocom.org down for me or for everybody?

$ host -6 bb.osmocom.org
bb.osmocom.org has address 213.95.46.201
bb.osmocom.org has IPv6 address 2001:780:45:f046::201

$ ping6 2001:780:45:f046::201
PING 2001:780:45:f046::201(2001:780:45:f046::201) 56 data bytes
^C
--- 2001:780:45:f046::201 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 4999ms

$ telnet 2001:780:45:f046::201 80
Trying 2001:780:45:f046::201...
telnet: connect to address 2001:780:45:f046::201: Connection timed out


$ traceroute 2001:780:45:f046::201
traceroute to 2001:780:45:f046::201 (2001:780:45:f046::201), 30 hops 
max, 80 byte packets
 1  * * *
 2  gige-g2-4.core1.fra1.he.net (2001:470:0:69::1)  75.265 ms  75.266 
ms  75.552 ms
 3  gi0-3-rt1-ffm2.core.noris.net (2001:7f8::3031:0:1)  72.963 ms  
72.883 ms  72.891 ms
 4  vl604-rt3-nbg3.core.noris.net (2001:780:40:10::1)  75.429 ms  
75.448 ms  75.416 ms
 5  fa0-0-31-rt6-nbg3.access.noris.net (2001:780:40:23::5)  75.374 ms  
75.048 ms  75.128 ms
 6  2001:780:0:f::13 (2001:780:0:f::13)  75.030 ms  50.987 ms  50.882 ms
 7  * * *
 8  * * *
(...)
29  * * *
30  * * *

Regards,
Andr??.




From laforge at gnumonks.org  Fri Sep 23 07:38:24 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 23 Sep 2011 09:38:24 +0200
Subject: IPv6 connectivity to bb.osmocom.org
In-Reply-To: <cmu-lmtpd-21843-1316699073-0@ganesha>
References: <cmu-lmtpd-21843-1316699073-0@ganesha>
Message-ID: <4E7C3770.5000504@gnumonks.org>

On 09/22/2011 11:24 AM, AndrXX wrote:
> Hi All,
>
> Is IPv6 connectivity to  bb.osmocom.org down for me or for everybody?

Yes, this was a configuration error after I did some major network 
reconfiguration two days ago.  Thanks for pointing it out, it's fixed now.

Regards,
	Harald



From sebastien at lorquet.fr  Thu Sep 22 13:25:51 2011
From: sebastien at lorquet.fr (=?utf-8?b?U8OpYmFzdGllbg==?= Lorquet)
Date: Thu, 22 Sep 2011 15:25:51 +0200
Subject: what about femtocells?
Message-ID: <20110922152551.Horde.qbzZb3fM5mBOezdfXC4EdWA@www.unsads.com>

Hi all,

Do you see any interest in the domain of femtocells?

this model, that will be sold in France, claims to be pluggable  
(probably via ethernet) into nearly any ISP provided home router  
(internet "box").

http://www.pcinpact.com/actu/news/65810-sfr-mobile-adsl-3g-femto.htm

Is it in any way comparable to the nanoBTS and other stuff you're  
hacking nowadays ?

Regards

Sebastien



From alexander.huemer at xx.vu  Thu Sep 22 14:34:27 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Thu, 22 Sep 2011 16:34:27 +0200
Subject: what about femtocells?
In-Reply-To: <20110922152551.Horde.qbzZb3fM5mBOezdfXC4EdWA@www.unsads.com>
References: <20110922152551.Horde.qbzZb3fM5mBOezdfXC4EdWA@www.unsads.com>
Message-ID: <20110922143427.GA25795@de.xx.vu>

On Thu, Sep 22, 2011 at 03:25:51PM +0200, S?bastien Lorquet wrote:
> Do you see any interest in the domain of femtocells?
Of course.
There is already support for one in openbsc [1].
> this model, that will be sold in France, claims to be pluggable
> (probably via ethernet) into nearly any ISP provided home router
> (internet "box").
> 
> http://www.pcinpact.com/actu/news/65810-sfr-mobile-adsl-3g-femto.htm
> 
> Is it in any way comparable to the nanoBTS and other stuff you're
> hacking nowadays ?
AFAIK this device is 3G only.
Since there is no 3G support in openbsc (yet), I am afraid there is
not much value in the device for openbsc at the moment.
Please don't take my statements as authoritative, I'm not a dev of the
project.
By the way, openbsc has it's own ML [2].

For a bit more information, see [4].

Kind regards,
-Alexander Huemer

[1] http://openbsc.osmocom.org/trac/wiki/HSL_Femto
[2] http://lists.osmocom.org/pipermail/openbsc/2010-December/002296.html
[3] http://openbsc.osmocom.org/trac/#Developers




From ml at mail.tsaitgaist.info  Thu Sep 22 15:16:39 2011
From: ml at mail.tsaitgaist.info (tsaitgaist)
Date: Thu, 22 Sep 2011 17:16:39 +0200
Subject: what about femtocells?
In-Reply-To: <20110922152551.Horde.qbzZb3fM5mBOezdfXC4EdWA@www.unsads.com>
References: <20110922152551.Horde.qbzZb3fM5mBOezdfXC4EdWA@www.unsads.com>
Message-ID: <4E7B5157.8000407@mail.tsaitgaist.info>

Hi S?bastien,

On 22.09.2011 15:25, S?bastien Lorquet wrote:
> Hi all,
> 
> Do you see any interest in the domain of femtocells?

Osmocom is actively working on a 2G femtocell (BTS).
3G femtocells (NodeB) uses an UMTS stack.
It is not a phone baseband. The openBSC list is more appropriate.
Also it's 3G, it's a bit different from GSM which osmocom is about
currently. There is no free implementation of a 3G stack yet.

> 
> this model, that will be sold in France, claims to be pluggable
> (probably via ethernet) into nearly any ISP provided home router
> (internet "box").
> 
> http://www.pcinpact.com/actu/news/65810-sfr-mobile-adsl-3g-femto.htm

This is the second version on the femtocell provided by this operator.
The first one was Ethernet only. This one mainly uses USB but also
provides an Ethernet port.
The limiting factor is that one needs a mobile phone subscription from
this operator to order the femtocell.
Getting such a device is not possible (hard) for everyone.

> 
> Is it in any way comparable to the nanoBTS and other stuff you're
> hacking nowadays ?

nanoBTS uses GSM while this femtocell uses 3G. The protocols are different.
Moreover, the architecture is also a bit different. Femtocell are more
then just transceivers.
But if you are interested, this femtocell (the first version) has
already been abused.
More information on http://femto.sec.t-labs.tu-berlin.de/ , or just ask
the involved team.

Good luck,
Kevin



From izsh at fail0verflow.com  Fri Sep 23 14:18:44 2011
From: izsh at fail0verflow.com (iZsh)
Date: Fri, 23 Sep 2011 16:18:44 +0200
Subject: Proposed patch for libosmocore/gsmtap
Message-ID: <77F333FD-D30B-44F8-876F-43197376A465@fail0verflow.com>

Please find attached a proposed patch for libosmocore

The modifications are needed if we want to be able to send a gsmtap packet with a type different than GSMTAP_TYPE_UM.

It's a fairly straightforward patch.

Best Regards,
iZsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsmtap_ex.patch
Type: application/octet-stream
Size: 3899 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110923/d4354b1c/attachment.obj>

From aegean2000 at 21cn.com  Mon Sep 26 05:08:43 2011
From: aegean2000 at 21cn.com (Aegean Chou)
Date: Mon, 26 Sep 2011 13:08:43 +0800
Subject: About sniff multi bursts in a frame, CCCH_CONF
Message-ID: <20110926050842.AABF63821E@21cn.com>

Dear all,

	the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.
	but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
	my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).

	i read the source briefly, and modify prim_rx_nb.c line "l1s_rx_win_ctrl(arfcn, L1_RXWIN_NB, 0);" for TS2, TS4, TS6 temporarily,
	but this way i'll need 4 phones to catch ONE station. it's very strange, and not beauty.

	i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
	i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks 

Best Regards
Steve



From 246tnt at gmail.com  Mon Sep 26 06:10:17 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 26 Sep 2011 08:10:17 +0200
Subject: About sniff multi bursts in a frame, CCCH_CONF
In-Reply-To: <20110926050842.AABF63821E@21cn.com>
References: <20110926050842.AABF63821E@21cn.com>
Message-ID: <CAHL+j0_tJR3zVaVbG4S3EeEQxq=oKLGtOfVJ3H=3EBLbRvCEgg@mail.gmail.com>

> ? ? ? ?the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.

Mmm ,interesting, I had never seen that option being used before. What
network is this.

> ? ? ? ?but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
> ? ? ? ?my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).

Well, it's your own phone (or any known target phone), you know the
IMSI, hence the paging group ...


> ? ? ? ?i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
> ? ? ? ?i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks

That's gonna be _very_ hard, the DSP uses _plenty_ of global variables ...

But OTOH, instead of using the normal 'RX task', you can use the sniff
task to listen to the CCCH. The sniff task will _not_ do the channel
decoding (i.e. you'll have to call xcch_decode to get the actual 23
bytes L2 frame), but it can sniff up to 4 bursts in a frame. just look
at how sdcch sniffing is done, it currently sniff 2 timeslot 0 & 3 (to
get DL & UL).

This way you won't need any hard DSP patching, just a minor patch on
the firmware to convert CCCH listening to burst_ind (leave the BCCH
task as-it is, just mod the CCCH). And then a patch in the host app to
call xcch_decode appropriately and feed the results 'as if' it cames
from the phone directly.

Cheers,

    Sylvain



From aegean2000 at 21cn.com  Mon Sep 26 09:28:57 2011
From: aegean2000 at 21cn.com (=?utf-8?B?QWVnZWFuIENob3U=?=)
Date: Mon, 26 Sep 2011 17:28:57 +0800
Subject: =?utf-8?B?UmU6IFJlOiBBYm91dCBzbmlmZiBtdWx0aSBidXJzdHMgaW4gYSBmcmFtZSwgQ0NDSF9DT05G?=
Message-ID: <20110926092856.53F4C381D0@21cn.com>

Hi, Sylvain Munaut

	It's china mobile, i can provide more information if you need.
	Thanks for pointing out the right way, i'll try to modify codes according to BCCH'.

	BTW, i modify TS (line l1s_rx_win_ctrl _ONLY_) from 0 to 2, 4 and 6, the TS2 and TS4 work well, but the TS6 crash very soon because FCCH error,
	for example, what's wrong? (high TS -> low TS)?

THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Installing DSP sniff patch
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 1831!
L1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionFB0 (11:6): TOA= 7200, Power= -69dBm, Angle= 3691Hz
FB1 (21:8): TOA= 9651, Power= -69dBm, Angle=  103Hz
  fn_offset=20 (fn=21 + attempt=8 + ntdma = 7)
  delay=9 (fn_offset=20 + 11 - fn=21 - 1
  scheduling next FB/SB detection task with delay 9
=>FB @ FNR 20 fn_offset=20 qbits=3420
Synchronize_TDMA
LOST 3186!
SB1 (46:1): TOA=   29, Power= -69dBm, Angle=  217Hz
=> SB 0x00c12184: BSIC=33 fn=89118(67/16/21) qbits=24
Synchronize_TDMA
=>FB @ FNR 45 fn_offset=89118 qbits=4932
LOST 1912!
TOA AVG is not 16 qbits, correcting (got 20)
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x41, tsc=1)
LOST 2110!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3515!
FB0 (91861:3): TOA= 2544, Power= -67dBm, Angle= 3754Hz
FB1 (91871:8): TOA= 8751, Power= -67dBm, Angle=   40Hz
  fn_offset=91869 (fn=91871 + attempt=8 + ntdma = 6)
  delay=8 (fn_offset=91869 + 11 - fn=91871 - 1
  scheduling next FB/SB detection task with delay 8
=>FB @ FNR 91869 fn_offset=91869 qbits=4820
Synchronize_TDMA
LOST 3711!
SB1 (183745:1): TOA=   29, Power= -67dBm, Angle=  160Hz
=> SB 0x01e12284: BSIC=33 fn=91882(69/24/31) qbits=24
Synchronize_TDMA
=>FB @ FNR 183744 fn_offset=91882 qbits=4932
LOST 1912!
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x69, tsc=1)
LOST 2109!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3516!
FB0 (92514:8): TOA= 8784, Power= -67dBm, Angle= 3696Hz
FB1 (92524:8): TOA= 8755, Power= -67dBm, Angle=   69Hz
  fn_offset=92522 (fn=92524 + attempt=8 + ntdma = 6)
  delay=8 (fn_offset=92522 + 11 - fn=92524 - 1
  scheduling next FB/SB detection task with delay 8
=>FB @ FNR 92522 fn_offset=92522 qbits=4836
Synchronize_TDMA
LOST 3717!
SB1 (185051:1): TOA=   27, Power= -66dBm, Angle=   47Hz
=> SB 0x00852284: BSIC=33 fn=92535(69/ 1/21) qbits=16
Synchronize_TDMA
=>FB @ FNR 185050 fn_offset=92535 qbits=4924
LOST 1909!
TOA AVG is not 16 qbits, correcting (got 19)
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x73, tsc=1)
LOST 2578!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3047!
FB0 (93574:9): TOA=10032, Power= -72dBm, Angle= 3770Hz
FB1 (93585:9): TOA=10003, Power= -72dBm, Angle=  -11Hz
  fn_offset=93583 (fn=93585 + attempt=9 + ntdma = 7)
  delay=8 (fn_offset=93583 + 11 - fn=93585 - 1
  scheduling next FB/SB detection task with delay 8
=>FB @ FNR 93583 fn_offset=93583 qbits=4828
Synchronize_TDMA
LOST 3713!
SB1 (187172:1): TOA=   27, Power= -72dBm, Angle=  132Hz
=> SB 0x01582384: BSIC=33 fn=93596(70/22/11) qbits=16
Synchronize_TDMA
=>FB @ FNR 187171 fn_offset=93596 qbits=4924
LOST 1910!
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x43, tsc=1)
LOST 2578!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3047!
FB0 (94186:1): TOA=   48, Power= -68dBm, Angle= 3743Hz
FB1 (94197:9): TOA=10007, Power= -68dBm, Angle= 3738Hz
  fn_offset=94195 (fn=94197 + attempt=9 + ntdma = 7)
  delay=8 (fn_offset=94195 + 11 - fn=94197 - 1
  scheduling next FB/SB detection task with delay 8
FB1 (94217:11): TOA=12507, Power= -68dBm, Angle= 3783Hz
  fn_offset=94215 (fn=94217 + attempt=11 + ntdma = 9)
  delay=8 (fn_offset=94215 + 11 - fn=94217 - 1
  scheduling next FB/SB detection task with delay 8
FB1 (94237:11): TOA=12507, Power= -69dBm, Angle= 3743Hz
  fn_offset=94235 (fn=94237 + attempt=11 + ntdma = 9)
  delay=8 (fn_offset=94235 + 11 - fn=94237 - 1
  scheduling next FB/SB detection task with delay 8
FB1 (94248:2): TOA= 1259, Power= -69dBm, Angle= 3689Hz
  fn_offset=94246 (fn=94248 + attempt=2 + ntdma = 0)
  delay=8 (fn_offset=94246 + 11 - fn=94248 - 1
  scheduling next FB/SB detection task with delay 8
... ...

======= 2011-09-26 14:10:17 =======

>> ? ? ? ?the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.
>
>Mmm ,interesting, I had never seen that option being used before. What
>network is this.
>
>> ? ? ? ?but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
>> ? ? ? ?my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).
>
>Well, it's your own phone (or any known target phone), you know the
>IMSI, hence the paging group ...
>
>
>> ? ? ? ?i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
>> ? ? ? ?i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks
>
>That's gonna be _very_ hard, the DSP uses _plenty_ of global variables ...
>
>But OTOH, instead of using the normal 'RX task', you can use the sniff
>task to listen to the CCCH. The sniff task will _not_ do the channel
>decoding (i.e. you'll have to call xcch_decode to get the actual 23
>bytes L2 frame), but it can sniff up to 4 bursts in a frame. just look
>at how sdcch sniffing is done, it currently sniff 2 timeslot 0 & 3 (to
>get DL & UL).
>
>This way you won't need any hard DSP patching, just a minor patch on
>the firmware to convert CCCH listening to burst_ind (leave the BCCH
>task as-it is, just mod the CCCH). And then a patch in the host app to
>call xcch_decode appropriately and feed the results 'as if' it cames
>from the phone directly.
>
>Cheers,
>
>    Sylvain

= = = = = = = = = = = = = = = = = = = =
			

Best regards
Steve				 


From 246tnt at gmail.com  Mon Sep 26 09:37:45 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 26 Sep 2011 11:37:45 +0200
Subject: About sniff multi bursts in a frame, CCCH_CONF
In-Reply-To: <20110926092856.53F4C381D0@21cn.com>
References: <20110926092856.53F4C381D0@21cn.com>
Message-ID: <CAHL+j0-ti8wsxEoYgqwVfHDPuG64vVkznfGktAc-ztqZNy_7og@mail.gmail.com>

> ? ? ? ?BTW, i modify TS (line l1s_rx_win_ctrl _ONLY_) from 0 to 2, 4 and 6, the TS2 and TS4 work well, but the TS6 crash very soon because FCCH error,

Because the DSP doesn't have enough time to process the data between
the end of timeslot 6 and the next interrupt. Which causes a desync
between the TPU and DSP and then hell breaks loose and nothing will
work until a reset.

In theory when the phone is in another timeslot, we don't change the
RX window, we change the alignement of the interrupt. (but then that
means you can only listen to 1 timeslot).

When you use the burst sniff mode, it *should* still work for TS=6
this way (it's tight, but it fits). Because the phone doesn't need to
do all the channel decoding stuff, it's left to the PC.

Cheers,

    Sylvain



From xyzzy at mm.st  Wed Sep 28 04:16:05 2011
From: xyzzy at mm.st (Richard James)
Date: Wed, 28 Sep 2011 00:16:05 -0400
Subject: libosmocore patch to support custom baud rates on OS X
Message-ID: <1317183365.21077.140258148544101@webmail.messagingengine.com>

This patch should allow custom baud-rate setting to work on OS X; tested
on Mac OS X 10.7 with a FT232BL-based adapter.


diff --git a/src/shared/libosmocore/src/serial.c
b/src/shared/libosmocore/src/serial.c
index 26cf59d..d702153 100644
--- a/src/shared/libosmocore/src/serial.c
+++ b/src/shared/libosmocore/src/serial.c
@@ -38,8 +38,9 @@
 #include <sys/ioctl.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#ifdef __linux__
 #include <linux/serial.h>
-
+#endif
 
 #include <osmocom/core/serial.h>
 
@@ -155,6 +156,7 @@ osmo_serial_set_baudrate(int fd, speed_t baudrate)
 int
 osmo_serial_set_custom_baudrate(int fd, int baudrate)
 {
+#ifdef __linux__
 	int rc;
 	struct serial_struct ser_info;
 
@@ -174,6 +176,23 @@ osmo_serial_set_custom_baudrate(int fd, int
baudrate)
 	}
 
 	return _osmo_serial_set_baudrate(fd, B38400); /* 38400 is a kind
 	of magic ... */
+#elsif defined(__APPLE__)
+#ifndef IOSSIOSPEED
+#define IOSSIOSPEED    _IOW('T', 2, speed_t)
+#endif
+    int rc;
+    
+    unsigned int speed = baudrate;
+    rc = ioctl(fd, IOSSIOSPEED, &speed);
+    if (rc < 0) {
+        dbg.perror("ioctl(IOSSIOSPEED)");
+        return -errno;
+    }
+    return 0;
+#else
+#warning osmo_serial_set_custom_baudrate: unsupported platform
+    return 0;
+#endif
 }
 
 /*! \brief Clear any custom baudrate
@@ -186,6 +205,7 @@ int
 osmo_serial_clear_custom_baudrate(int fd)
 {
 	int rc;
+#ifdef __linux__
 	struct serial_struct ser_info;
 
 	rc = ioctl(fd, TIOCGSERIAL, &ser_info);
@@ -202,7 +222,7 @@ osmo_serial_clear_custom_baudrate(int fd)
 		dbg_perror("ioctl(TIOCSSERIAL)");
 		return -errno;
 	}
-
+#endif
 	return 0;
 }
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: set_custom_baudrate_osx.patch
Type: application/octet-stream
Size: 1511 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110928/4538b332/attachment.obj>

From catchall at blombo.de  Wed Sep 28 06:31:08 2011
From: catchall at blombo.de (Martin Auer)
Date: Wed, 28 Sep 2011 08:31:08 +0200
Subject: libosmocore patch to support custom baud rates on OS X
In-Reply-To: <1317183365.21077.140258148544101@webmail.messagingengine.com>
References: <1317183365.21077.140258148544101@webmail.messagingengine.com>
Message-ID: <F636783E-FF97-419B-BBAC-13A4D2E86A77@blombo.de>


Am 28.09.2011 um 06:16 schrieb Richard James:

> This patch should allow custom baud-rate setting to work on OS X; tested
> on Mac OS X 10.7 with a FT232BL-based adapter.
> 
Thanks very much, that solved my problem reported some days ago.
> 
> 
> 
> <set_custom_baudrate_osx.patch>




From aegean2000 at 21cn.com  Wed Sep 28 04:41:13 2011
From: aegean2000 at 21cn.com (Aegean Chou)
Date: Wed, 28 Sep 2011 12:41:13 +0800
Subject: =?utf-8?B?QWJvdXQgc25pZmYgbXVsdGkgYnVyc3RzIGluIGEgZnJhbWUsIENDQ0hfQ09ORg==?=
Message-ID: <20110928044122.9ED89506F99@21cn.com>

Hi, Sylvain Munaut

	Another method, same error, and i tried any _ONE_ ts, it's no problem.

static const struct mframe_sched_item mf_ccch[] = {
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 6 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 6 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 6 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 6 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 12 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 12 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 12 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 12 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 16 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 16 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 16 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 16 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 22 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 22 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 22 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 22 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 26 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 26 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 26 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 26 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 32 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 32 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 32 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 32 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 36 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 36 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 36 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 36 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 42 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 42 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 42 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 42 },
	{ .sched_set = SNIFF_CCCH0, .modulo = 51, .frame_nr = 46 },
	{ .sched_set = SNIFF_CCCH2, .modulo = 51, .frame_nr = 46 },
	{ .sched_set = SNIFF_CCCH4, .modulo = 51, .frame_nr = 46 },
	{ .sched_set = SNIFF_CCCH6, .modulo = 51, .frame_nr = 46 },
	{ .sched_set = NULL }
};

const struct tdma_sched_item sniff_ccch0_sched_set[] = {
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 0),	SCHED_END_FRAME(),
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 1),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 0, 0),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 2),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 0, 1),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 3),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 0, 2),   SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 0, 3),	SCHED_END_FRAME(),
	SCHED_END_SET()
};
const struct tdma_sched_item sniff_ccch2_sched_set[] = {
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 4, 0),	SCHED_END_FRAME(),
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 4, 1),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 4, 0),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 4, 2),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 4, 1),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 4, 3),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 4, 2),   SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 4, 3),	SCHED_END_FRAME(),
	SCHED_END_SET()
};
const struct tdma_sched_item sniff_ccch4_sched_set[] = {
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 8, 0),	SCHED_END_FRAME(),
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 8, 1),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 8, 0),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 8, 2),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 8, 1),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 8, 3),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 8, 2),   SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 8, 3),	SCHED_END_FRAME(),
	SCHED_END_SET()
};
const struct tdma_sched_item sniff_ccch6_sched_set[] = {
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 12, 0),	SCHED_END_FRAME(),
						SCHED_ITEM_DT(l1s_sniff_cmd, 0, 12, 1),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 12, 0),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 12, 2),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 12, 1),	SCHED_ITEM_DT(l1s_sniff_cmd, 0, 12, 3),	SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 12, 2),   SCHED_END_FRAME(),
	SCHED_ITEM(l1s_sniff_resp, -5, 12, 3),	SCHED_END_FRAME(),
	SCHED_END_SET()
};

======= 2011-09-26 14:10:17 =======

>> ? ? ? ?the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.
>
>Mmm ,interesting, I had never seen that option being used before. What
>network is this.
>
>> ? ? ? ?but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
>> ? ? ? ?my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).
>
>Well, it's your own phone (or any known target phone), you know the
>IMSI, hence the paging group ...
>
>
>> ? ? ? ?i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
>> ? ? ? ?i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks
>
>That's gonna be _very_ hard, the DSP uses _plenty_ of global variables ...
>
>But OTOH, instead of using the normal 'RX task', you can use the sniff
>task to listen to the CCCH. The sniff task will _not_ do the channel
>decoding (i.e. you'll have to call xcch_decode to get the actual 23
>bytes L2 frame), but it can sniff up to 4 bursts in a frame. just look
>at how sdcch sniffing is done, it currently sniff 2 timeslot 0 & 3 (to
>get DL & UL).
>
>This way you won't need any hard DSP patching, just a minor patch on
>the firmware to convert CCCH listening to burst_ind (leave the BCCH
>task as-it is, just mod the CCCH). And then a patch in the host app to
>call xcch_decode appropriately and feed the results 'as if' it cames
>from the phone directly.
>
>Cheers,
>
>    Sylvain

= = = = = = = = = = = = = = = = = = = =
			

Best regards
				 
????????Aegean Chou
????????aegean2000 at 21cn.com
??????????2011-09-28


From 246tnt at gmail.com  Wed Sep 28 06:31:54 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 28 Sep 2011 08:31:54 +0200
Subject: About sniff multi bursts in a frame, CCCH_CONF
In-Reply-To: <20110928044122.9ED89506F99@21cn.com>
References: <20110928044122.9ED89506F99@21cn.com>
Message-ID: <CAHL+j0_aAB6O3SoqosrVZQ494b-arO4QiJvdK-g_JB0vk6sQqw@mail.gmail.com>

Hi,

> const struct tdma_sched_item sniff_ccch0_sched_set[] = {
>                                                SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 0),  SCHED_END_FRAME(),
>                                                SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 1),  SCHED_END_FRAME(),
>        SCHED_ITEM(l1s_sniff_resp, -5, 0, 0),   SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 2),  SCHED_END_FRAME(),
>        SCHED_ITEM(l1s_sniff_resp, -5, 0, 1),   SCHED_ITEM_DT(l1s_sniff_cmd, 0, 0, 3),  SCHED_END_FRAME(),
>        SCHED_ITEM(l1s_sniff_resp, -5, 0, 2),   SCHED_END_FRAME(),
>        SCHED_ITEM(l1s_sniff_resp, -5, 0, 3),   SCHED_END_FRAME(),
>        SCHED_END_SET()
> };

You must set the 'priority' field properly as well. It defines in
which order the item will be executed in a frame.

For TSx command, put it as x
For TSx response, put it as -12+x

So for TS2, the l1s_sniff_cmd would be 2 and the l1s_sniff_resp would be -10

Cheers,

    Sylvain



From b.alecu at yahoo.com  Fri Sep 30 07:51:48 2011
From: b.alecu at yahoo.com (Bogdan Alecu)
Date: Fri, 30 Sep 2011 00:51:48 -0700 (PDT)
Subject: Layer23 missing
Message-ID: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>

Hello,

I'm trying to use the gprsdecode but when I try to patch it there is no layer3.c and also it can't find "

d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5" in the tree. Can someone explain a little bit the new steps?

Regards,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110930/6002aed9/attachment.htm>

From luca.bongiorni1 at studenti.unimi.it  Fri Sep 30 11:15:37 2011
From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni)
Date: Fri, 30 Sep 2011 13:15:37 +0200
Subject: R: Layer23 missing
In-Reply-To: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
Message-ID: <76a0af3d4494.4e85c0f9@studenti.unimi.it>

Hi Bogdan,
is better if you will patch the new version of burst_ind [1].

Acutally i don't have with me the modified patch, but takes two minutes to patch manually.

Eg. ?on ?osmocom-bb/src/host/layer23/src/misc/app_ccch_scan.c ?change the following line:

?	/* Discard packet TBF assignement */
-	if (ia->page_mode & 0xf0)
+	if ((ia->page_mode & 0xf0) != 0x10)

Obviously with the new burst_ind you will have to use ./ccch_scan instead of ./layer23

Regards,
Luca

[1]?http://bb.osmocom.org/trac/browser/src?rev=500506cb3aa19a55fd30014a8af18df53a108801


> Hello,
> I'm trying to use the gprsdecode but when I try to patch it there is no layer3.c and also it can't find "
>?
> d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5" in the tree. Can someone explain a little bit the new steps?
>?
> Regards,
> Bogdan
?



From luca.bongiorni1 at studenti.unimi.it  Fri Sep 30 12:32:50 2011
From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni)
Date: Fri, 30 Sep 2011 14:32:50 +0200
Subject: R: Re: R: Layer23 missing
In-Reply-To: <1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
	<76a0af3d4494.4e85c0f9@studenti.unimi.it>
	<1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
Message-ID: <76c0c70e1958.4e85d312@studenti.unimi.it>

Hi Bogdan,

> I've used all types of phones and different?networks - same result. If I capture the uplink then every time after a?
> few seconds I get "segmentation fault". My guess is that in a controlled?environment it's going to work, but with a live one, where you have a?
> lot of arfcn (on a quick scan I get about 50 on my location) it's?unlikely to work.?

well, the success could depends from many things:
- wich cable are you using: FTDI or CP2102;
- which phone you have tried: sometimes the jack on C1xx could be not so clean or used and it could create problems of communication at high baudrates.
- the environment that you are using: public network, as i saw from my tests, is quite horrible to make tests (eg. arfcn hopping).

Using a DP-L10 and modifying the AFC value, seems to work well on public netwroks, even if, sometimes it get stuck: problem related with channel hopping/sync IIRC.

I used a Blackberry Test Field to disable EDGE and identify which ARFCN that doesn't hop on GPRS: ( eg. this one is hopping, others may not [1] )?

Obviously a private and controlled environment could give you the full percentage of success.

Regards,
Luca

[1]?http://tinyurl.com/gprs-hopping



From alexander.chemeris at gmail.com  Fri Sep 30 12:57:02 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Fri, 30 Sep 2011 16:57:02 +0400
Subject: R: Layer23 missing
In-Reply-To: <76c0c70e1958.4e85d312@studenti.unimi.it>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
	<76a0af3d4494.4e85c0f9@studenti.unimi.it>
	<1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
	<76c0c70e1958.4e85d312@studenti.unimi.it>
Message-ID: <CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>

Luca,

On Fri, Sep 30, 2011 at 16:32, Luca Bongiorni
<luca.bongiorni1 at studenti.unimi.it> wrote:
> I used a Blackberry Test Field to disable EDGE and identify which ARFCN that doesn't hop on GPRS: ( eg. this one is hopping, others may not [1] )

Could you clarify how did you do this?
Following your recommendation I recently got a BlackBerry too, but
after a quick look into its engineering menu I didn't find how to
disable EDGE.

And a related question. It requires a code to enter to the engineering
menu. Do you have any script for calculating it offline?

(I'm sorry for off-topic, but I think this may be interesting for
other people too, because BlackBerry engineering menu is really that
good)

-- 
Regards,
Alexander Chemeris.



From b.alecu at yahoo.com  Fri Sep 30 13:15:13 2011
From: b.alecu at yahoo.com (Bogdan Alecu)
Date: Fri, 30 Sep 2011 06:15:13 -0700 (PDT)
Subject: R: Layer23 missing
In-Reply-To: <CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
	<76a0af3d4494.4e85c0f9@studenti.unimi.it>
	<1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
	<76c0c70e1958.4e85d312@studenti.unimi.it>
	<CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>
Message-ID: <1317388513.41049.YahooMailNeo@web46214.mail.sp1.yahoo.com>

Hello,

Luca thanks for your reply. Regarding the phone I used, there were a few smartphones which I put them in EDGE mode, but also some older like Nokia 6310i which only knows GPRS. The cable is FTDI. However I haven't got any luck - only a few times I get somthing that can be decrypted but there are only 2-3 malformed packets.
There is also the problem with large bursts - every time (downlink or uplink, doesn't matter) the capture stops.

Cheers,
Bogdan



________________________________
From: Alexander Chemeris <alexander.chemeris at gmail.com>
To: Luca Bongiorni <luca.bongiorni1 at studenti.unimi.it>
Cc: Bogdan Alecu <b.alecu at yahoo.com>; "baseband-devel at lists.osmocom.org" <baseband-devel at lists.osmocom.org>
Sent: Friday, September 30, 2011 3:57 PM
Subject: Re: Re: R: Layer23 missing

Luca,

On Fri, Sep 30, 2011 at 16:32, Luca Bongiorni
<luca.bongiorni1 at studenti.unimi.it> wrote:
> I used a Blackberry Test Field to disable EDGE and identify which ARFCN that doesn't hop on GPRS: ( eg. this one is hopping, others may not [1] )

Could you clarify how did you do this?
Following your recommendation I recently got a BlackBerry too, but
after a quick look into its engineering menu I didn't find how to
disable EDGE.

And a related question. It requires a code to enter to the engineering
menu. Do you have any script for calculating it offline?

(I'm sorry for off-topic, but I think this may be interesting for
other people too, because BlackBerry engineering menu is really that
good)

-- 
Regards,
Alexander Chemeris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110930/854b3a0d/attachment.htm>

From luca.bongiorni1 at studenti.unimi.it  Fri Sep 30 13:26:56 2011
From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni)
Date: Fri, 30 Sep 2011 15:26:56 +0200
Subject: R: Re: Re: R: Layer23 missing
In-Reply-To: <1317388513.41049.YahooMailNeo@web46214.mail.sp1.yahoo.com>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
	<76a0af3d4494.4e85c0f9@studenti.unimi.it>
	<1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
	<76c0c70e1958.4e85d312@studenti.unimi.it>
	<CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>
	<1317388513.41049.YahooMailNeo@web46214.mail.sp1.yahoo.com>
Message-ID: <76f0df786904.4e85dfc0@studenti.unimi.it>

Bogdan,
> There is also the problem with large bursts - every time (downlink or uplink, doesn't matter) the capture stops.


That is another issue that i verified and i didn't still find a solution.


If i dump a "short" session (eg. using the field test, by sending icmp pings from the blackberry to google's ip) i got the entire packets, instead, if i try to dump a "bigger" session the DP-L10 sutck.


Btw, someone has some hints where could i look about this issue?


Regards,
Luca






From luca.bongiorni1 at studenti.unimi.it  Fri Sep 30 13:20:29 2011
From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni)
Date: Fri, 30 Sep 2011 15:20:29 +0200
Subject: Blackberry Field Test Mode
In-Reply-To: <CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
	<76a0af3d4494.4e85c0f9@studenti.unimi.it>
	<1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
	<76c0c70e1958.4e85d312@studenti.unimi.it>
	<CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>
Message-ID: <7700a29f3899.4e85de3d@studenti.unimi.it>

Hi Alexander,

here it is the script to enable the blackberry field test mode:

http://www.webalice.it/zibri/escr.html

Just download the page and you will be able to use it offline. (For instructions [1])

About, how to disable EDGE, you need to disable 8PSK modulation: with public networks, using this option, the bb doesn't use EDGE. [2]

P.S: About finding a non-hopping GRPS arfcn...?http://tinyurl.com/5vzx5jp
[1]?http://www.zibri.org/2009/08/hidden-things-are-usually-best.html
[2]?http://tinyurl.com/edge-disabled


Regards,
Luca






From alexander.chemeris at gmail.com  Fri Sep 30 13:29:14 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Fri, 30 Sep 2011 17:29:14 +0400
Subject: Blackberry Field Test Mode
In-Reply-To: <7700a29f3899.4e85de3d@studenti.unimi.it>
References: <1317369108.230.YahooMailNeo@web46214.mail.sp1.yahoo.com>
	<76a0af3d4494.4e85c0f9@studenti.unimi.it>
	<1317383604.47559.YahooMailNeo@web46211.mail.sp1.yahoo.com>
	<76c0c70e1958.4e85d312@studenti.unimi.it>
	<CABmJbFXYUOZ8Ca6xjMeR7yMbcfusPkFKH321O=un5CtP+QLRJw@mail.gmail.com>
	<7700a29f3899.4e85de3d@studenti.unimi.it>
Message-ID: <CABmJbFWSrevz1WRF3ewgyrdWWnO+2YeSoTWQWEDjK_voROqcUQ@mail.gmail.com>

Luca, thank you!
I'll try when I get to our Blackberry next time.

On Fri, Sep 30, 2011 at 17:20, Luca Bongiorni
<luca.bongiorni1 at studenti.unimi.it> wrote:
> Hi Alexander,
>
> here it is the script to enable the blackberry field test mode:
>
> http://www.webalice.it/zibri/escr.html
>
> Just download the page and you will be able to use it offline. (For instructions [1])
>
> About, how to disable EDGE, you need to disable 8PSK modulation: with public networks, using this option, the bb doesn't use EDGE. [2]
>
> P.S: About finding a non-hopping GRPS arfcn...?http://tinyurl.com/5vzx5jp
> [1]?http://www.zibri.org/2009/08/hidden-things-are-usually-best.html
> [2]?http://tinyurl.com/edge-disabled
>
>
> Regards,
> Luca
>
>
>
>



-- 
Regards,
Alexander Chemeris.



From b.alecu at yahoo.com  Fri Sep 30 11:52:41 2011
From: b.alecu at yahoo.com (Bogdan Alecu)
Date: Fri, 30 Sep 2011 04:52:41 -0700 (PDT)
Subject: baseband-devel Digest, Vol 20, Issue 26
In-Reply-To: <mailman.2.1317376801.10387.baseband-devel@lists.osmocom.org>
References: <mailman.2.1317376801.10387.baseband-devel@lists.osmocom.org>
Message-ID: <1317383561.89559.YahooMailNeo@web46212.mail.sp1.yahoo.com>

Hi Luca,

I've noticed the change and manual patched everything, but for me seems that it's not going to work. If I capture the downlink, sometimes it capture some bursts, other times not, but even so there is nothing to decode - the arfcn is correct. I've used all types of phones and different networks - same result. If I capture the uplink then every time after a few seconds I get "segmentation fault". My guess is that in a controlled environment it's going to work, but with a live one, where you have a lot of arfcn (on a quick scan I get about 50 on my location) it's unlikely to work.?

Bogdan



________________________________
From: "baseband-devel-request at lists.osmocom.org" <baseband-devel-request at lists.osmocom.org>
To: baseband-devel at lists.osmocom.org
Sent: Friday, September 30, 2011 1:00 PM
Subject: baseband-devel Digest, Vol 20, Issue 26

----- Forwarded Message -----

Send baseband-devel mailing list submissions to
??? baseband-devel at lists.osmocom.org

To subscribe or unsubscribe via the World Wide Web, visit
??? https://lists.osmocom.org/mailman/listinfo/baseband-devel
or, via email, send a message with subject or body 'help' to
??? baseband-devel-request at lists.osmocom.org

You can reach the person managing the list at
??? baseband-devel-owner at lists.osmocom.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of baseband-devel digest..."

Today's Topics:

?  1. Layer23 missing (Bogdan Alecu)

Hello,

I'm trying to use the gprsdecode but when I try to patch it there is no layer3.c and also it can't find "
d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5" in the tree. Can someone explain a little bit the new steps?

Regards,
Bogdan

_______________________________________________
baseband-devel mailing list
baseband-devel at lists.osmocom.org
https://lists.osmocom.org/mailman/listinfo/baseband-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110930/420b3fa0/attachment.htm>