i found this, searching google/codesearch for 'ftm_cmd'
svn co http://hwplatform.googlecode.com/svn/trunk/
about 1.5G of datasheets, sourcecode, and tools
for various phones.
willem
Hi!
I've written an introductory text on GSM mobile phone architecture,
and before officially posting/announcing it, I thought I'd invite
the members of this list to do some review and give feedback!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Jake (and others),
On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote:
> > I've written an introductory text on GSM mobile phone architecture,
> > and before officially posting/announcing it, I thought I'd invite
> > the members of this list to do some review and give feedback!
>
> Do you have the latex available? It's hard to edit and send a diff of a
> pdf...
see attachment.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi everyone,
prom is using the crc16 as implemented in the Linux Kernel for his bootloader
work, and I'm planning to add an optional crc16 check for sercomm. To have
crc16 easily accessible in baseband, this commit adds it to libosmocore.
Chris
Hi,
this patch adds a new DLCI, Numbered 11, which just echoes
whatever it recveices on the mobile back to the PC. It is
very useful for debugging serial port problems.
Chris
Hello Christian,
I had the suspicion that a UART reset in the code is missing,
however I could not verify that because I never had those
problems with wrong bytes.
Out of curiousity, have you tried if just the following line is
enough to fix the problems you noticed ?
> + uart_reg_write(uart, MDR1, 0x07); /* turn off UART */
This should cause the UART to be reset and I would expect that
setting the XON/XOFF characters is not needed as long XON/XOFF
handshake is not turned on.
Thanks and best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I've seen a lot of systematic character swaps on the serial port,
especially in the vincinity of 0-bytes. As the XON/XOFF registers
are the only thing in the UART that look like they would consider
the actual data sent, I've added this initialisation to uart.c
This makes the problem go away completely on my C123.
To check for it I've added CRCs to the HDLC protocol and checked
for bad frames, and also compared them in a (patched) osmocon
that just sends random garbate in a special DLCI. The bad
frames I observed always looked like this (number in
parenthesis define number of omitted bytes, for brevity):
<------ good bytes ----------> <-recvd|sent-> <----- identical again ------>
d0 e0 00 00..(107)..f7 ce 17 c4 < 0c 00|00 0c > db 70 ba cb..(67)..d8 6d 3a 1f
31 e1 00 00..(47)..38 ca 2f e5 < 0c 00|00 0c > f8 a3 77 5f..(127)..5b 72 ff 4a
<-- good -> <--- bad -----> <---- good again ------------->
dc e1 00 00 < 0c 00|00 0c > 87 cb 24 83..(178)..2f 69 b3 51
ae e2 00 00..(167)..bd 18 6f a1 < 0c 00|00 0c > 2f 53 d2 b2..(7)..da c7 1b 63
dc e3 00 00..(131)..8e 2c b0 a8 < 0c 00|00 0c > 40 62 56 5f..(43)..f0 3a 47 f7
Formerly I was observing about 10 packets for every 2000 sent (with 192
bytes of payload each). Now, with the added initialisation, I see
(as the time of writing this email) 12000 packets with 192 bytes each
sent, with 0 bytes missing, corrupted, flipped).
Please have a look and tell me if it's helping for you. I'll send the
HDLC/CRC patch in another email.
Chris
Hello Andreas,
On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i would like to participate (and others maybe too). what if we have
> somethink like a conference for all the people not in berlin?
>
> in our company we do it this way:
>
> - a conference number is dialed by all members.
> - a phone with hands free option can be used on one place where multiple
> members are.
> - netmeeting is used for presentation. this can also be via VNC remote
> desktop.
A conference call sounds good. If it is done this way, I would participate
too.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
when I tried to read the secure-romloader of an Alcatel VLE5-series
phone, I noticed a small bug in calypso_bootrom(), which prom already
tried to fix, but his fix only worked on targets which have nIBOOT tied
to high (Compal).
I've committed a fix for this to steve-m/pending.
Regards,
Steve
Hi!
Andreas has asked me about this, and it might be interesting to a wider
audience, so I've added the information to the wiki at
https://calypso.gnumonks.org/trac/wiki/libosmocore
Here's a copy of what I wrote there:
== Development Cycle ==
As we are still developing the GSM protocol stacks on the network side
(OpenBSC) and phone side (OsmocomBB),
every so often there is a need to add some new code to libosmocore.
Even worse, we sometimes need to break
the API and ABI of the library.
However, by keeping libosmocore in a separate git repository, we run
into one problem: Checking out an old
version of e.g. OpenBSC or OsmocomBB will result in failed builds, as we
don't remember which old version
of libosmocore was required. This makes debugging and things like git
bisect very hard to impossible.
In order to solve this problem, we use
[http://github.com/apenwarr/git-subtree git-subtree] to import the
full libosmocore.git repository into OsmocomBB.
This way, we ensure that there is always a compatible version of
libosmocore inside the tree if we check out old OsmocomBB versions from
git.
=== Making changes to libosmocore ===
'''NEVER COMMIT CHANGES DIRECTLY TO
osmocom-bb.git:src/shared/libosmocore'''
Instead, use the following process:
1. make your changes to your local copy of libosmocore
1. test them together with OsmocomBB and OpenBSC
1. test if libosmocore still builds for both host and target (ARM)
1. create a ''diff'' of your local libosmocore changes
1. apply that diff to the libosmocore.git repository
1. use the script in osmocom-bb.git/src/shared/update-libosmocore.sh
(uses git-subtree) to import your changes from libosmocore.git
1. test + commit your OsmocomBB changes that depend on the newly
introduced code to libosmocore
It is important that the steps are followed in the order state above to
ensure consistency of our repositories
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all!
As Andreas has pointed out to me in a phone call yesterday and steve-m
mentioned on IRC: Building layer23 with the not-installed (make
install) libosmocore from osmocom-bb resulted in link failures.
I've now addressed those problems and the repo should be building just
fine again.
Regards,
Harald.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Prom!
I've now merged (a rebased version of) your prom/pending, including the
manifest part.
Only one minor issue that I've noticed: 'make clean' does not remove
the board/*/*.manifest.o files. Maybe you can fix that at some point.
Also, I think it would be better to only export a 'struct manifest' that
then has members for all the various parameters (so far only strings
with versions, but there might be more stuff in the future).
Thanks,
Harald.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello Harald,
On Thu, 8 Apr 2010 05:18:15 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Also, layer1 TX side still has a problem where it transmits the bursts
> all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are
> received correctly by the BTS, the other burst is sent at a different
> (wrong!) point in time, disturbing some other phone on the same cell.
With my fix from a while ago sending works as expected. In the meantime
I extended my test code so that I could also verify the correct behaviour
against a GSM test set when doing a Location Update.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
currently i am working on radio ressource layer and the sub processes
for 1) network selection, 2) cell selection, and 3) location update
trigger process. i have problems expecially with the cell selection
task. since it requires measurements and detection of carriers (for some
time depending on the slot configuration), it must work together with
the layer 1 (radio part). here are some examples of messages what i
think must exist between layer 1 and cell selection process:
(the primitive names are just examples and do not conform to GSM specs.)
L1CTL_DM_EST_REQ (which already exists) tune to a channel in dedicated
mode (by given channel, frequency and later hopping sequence)
L1CTL_IM_EST_REQ tune to a BCCH channel in idle mode (by given
frequency)
L1CTL_IM_EST_CNF confirm valid carrier signal.
L1CTL_IM_INFO_IND info when reading of BCCH was enough for a cell
selection (depends on the channel configuration), shall include
measurement
L1CTL_MEAS_IND periodic info of measurements from the selected channel.
(required for cell reselection)
take these only as examples, not as required messages. while reading GSM
05.08, this is what i think is required to do cell (re-)selection
process or abort radio connection if fails (below minimum level).
any help/ideas/suggestions?
andreas
Hi Andreas,
some comments to your issues.txt:
> How do we send MEASUREMENT RESULTS to RSL? (maybe RSL_MT_MEAS_RES)
> what triggers the sending? Or do we just send it from time to time to
> layer 1 where it is stored and sent when the time is right? (Then we
> might get something like RSL_MT_MEAS_CNF, so we can send the next one,
> if we have new measurements available, otherwhise the L1 will use the
> old measurement results and resends them without confirming it.)
measurement results are sent on the SACCH. The Layer1 has independent
transmit queues for the main channel (SDCCH/TCH) and its associated
SACCH. So the L23 code needs to send the respective packet to a
chan_nr/link_id that indicates transmission over the SACCH.
In the GSM TS, there is a primitive by which L1 can indicate that it
needs the next L23 message for a given channel, which we don't implement
(as we're tunnelling L1CTL through HDLC/serial, the answer would never
be back before the next TDMA frame anyway).
My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in
L1CTL, and every time we actually dequeue the frame (i.e. send it to the
DSP), send an indication of the current queue depth up to L23. We
should do this for both the main and the ACCH queue so higher layers can
implement some kind of flow control if they want.
> I need some RACH primitives like:
> - RACH request (tx_ph_rach_req already exists) including value and
> offset of RACH slot from now.
What exactly do you mean with 'value and offset of RACH slot from now'?
As we're operating asynchronously "now" is not defined precisely. I
think if you simply tell the L1 that you want to transmit at a specified
GSM time (modulo 51), we can schedule it that way.
L23 should understand the current CCCH/BCCH layout and determine which
lsots are applicable for RACH burst transmission. They can then either
say "please transmit at this full gsm time (uint32_t of the frame
number)" or "please transmit in next multiframe at fn % 51 == X where X
is something specified by L23"
> - RACH confirm, the RACK has been sent (with timeslot where is was sent)
that should be relatively easy to add, I'll add it during the next days.
Meanwhile we can simply assume that it was sent at the timeslot as
requested.
> Since RACH request must be queued in layer 1 until it the right slot
> is reached, I need to tell L1 to cancel it. Whenever I receive a
> confirm, I schedule the next one until the maximum number has been
> transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH.
I think we can ignore that for now. In the worst case, we send one more
RACH request than needed. I know this is dangerous if done by many
phones on real networks, but for our current goal of "getting something
working in our own gsm test network" this is the kind of shortcut we can
take.
I know your development style is very different. You seem to be trying
to implement something thats fully compliant with the spec. I usually
try to take a more incremental/iterative approach. Make something work
first, and then iteratively improve/complete it. I hope you can live
with the fact that at least for now, L1 doesn't have this support. If
you want, we can already define the L1CTL message for it but simply
ignore it on L1 until its implemented.
> RACH request on RSL:
> Does it make sense to put RACH request to the set of RSLms primitives?
> (i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN)
> What do you say?
I think we should mark them explicitly as RSLms_MT_* to make it obvious
that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL" is
probably causing misunderstanding, lets just write the full word.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
I've added support for the Calypso "non-secure" romloader in my branch
steve-m/osmocon.
This means we now can execute our code on devices like the Motorola
W220, the BenQ A38 (which I've used for development), and the OpenMoko
devices (can anyone try to cross-compile osmocon and see if it works?).
For more information see in the wiki:
http://bb.osmocom.org/trac/wiki/CalypsoRomloader
I also added a new model switch for the C140 (-m c140), which
automatically adds the "1003" string in the uploaded binary.
This is meant for use with proms loader, so now you can upload
loader.ramload.bin on the C139/C140 and J100i, and load the application
itself with osmoload.
Regards,
Steve
Hi Harald,
That's a bright idea for all the developers behind the project as well as
those observers around the project to make a brainstorm with the development
and evolution of the project.
It's a little pity, however, for those people not going to participate
directly in the Developer Meeting at CCC near Berlin. If setting up a "green
pathway" connecting to the live meeting on the internet, so the people
strongly wanna share their ideas with others will be able to join into the
Developer Meeting simultaneously.
If there has difficulty in doing such things, maybe recording and uploading
the live video of the meeting into the public wiki of the project is another
way to share the content and fun of the meeting together with other people
all around the world.
Thanks.
Best Regards,
Samuel
On Mon, Apr 5, 2010 at 6:00 PM, <baseband-devel-request(a)lists.osmocom.org>wrote:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
> 1. Developer Meeting in Berlin / 2010-04-10 (Harald Welte)
> 2. Re: noisy cable? (Nathan Fain)
>
>
> ---------- Forwarded message ----------
> From: Harald Welte <laforge(a)gnumonks.org>
> To: baseband-devel(a)lists.osmocom.org
> Date: Mon, 5 Apr 2010 09:24:45 +0800
> Subject: Developer Meeting in Berlin / 2010-04-10
> Hi all!
>
> Since I'm returning from holidays in two days, I think it's a good idea
> (for those who are in/around Berlin) to meet again at CCC Berlin.
>
> This is mainly for me to get an idea where we are (compared to before my
> holidas) and how we proceed. Especially the loader seems to have made
> progress, as far as I can tell from casual reading of the commitlog.
>
> I'm also curious to see what's happening on the battery charger, sim
> card reader (and other) parts of the system.
>
> I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in
> joining, feel free to join!
>
> Cheers,
> Harald
> --
> - Harald Welte <laforge(a)gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
>
>
>
>
> ---------- Forwarded message ----------
> From: Nathan Fain <nat(a)fains.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Sun, 04 Apr 2010 22:17:38 -0700
> Subject: Re: noisy cable?
> fyi, using the /dev/cu.** variant solved my problem of osmocon being
> unable to write CMD1 to the port. At least, it worked with an FTDI
> cable I built. I imagine it will solve the issue with the prolific
> cable as well (will try later).
>
>
>
> On 29/03/2010 03:39, willem wrote:
> > i managed to get hello_world working on my c121, connected through a
> > pl2303 usb/serial cable to my macbookpro.
> >
> > but found that the connection is extremely noisy.
> > often the movement of me putting down the phone on the table is enough
> > to break the upload.
> > is that a common problem with these headphone/serial cable plugs?
> >
> >
> > for the serial device i can use /dev/cu.PL2303-0000201A
> > or /dev/tty.PL2303-0000201A
> >
> > but when using the '/dev/tty...' variant, i have to add this to
> osmocon.c
> >
> > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
> > index f934dd7..b361eb1 100644
> > --- a/src/host/osmocon/osmocon.c
> > +++ b/src/host/osmocon/osmocon.c
> > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
> > /* hardware flow control off */
> > options.c_cflag &= ~CRTSCTS;
> >
> > + /* ignore modem status lines */
> > + options.c_cflag |= CLOCAL;
> > +
> > /* software flow control off */
> > options.c_iflag &= ~(IXON | IXOFF | IXANY);
> >
> > =============================
> >
> > willem
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
hi harald,
i would like to participate (and others maybe too). what if we have somethink like a conference for all the people not in berlin?
in our company we do it this way:
- a conference number is dialed by all members.
- a phone with hands free option can be used on one place where multiple members are.
- netmeeting is used for presentation. this can also be via VNC remote desktop.
is it possible for you in berlin to establish a VNC server with multiple access, or at least something like a "screen" command?
my PRI test machine in my company can be used as conference server for up to 30 parties. it has a german dial-up number.
regrads,
andreas
-----Ursprüngliche Nachricht-----
Von: baseband-devel-bounces(a)lists.osmocom.org [mailto:baseband-devel-bounces@lists.osmocom.org] Im Auftrag von Harald Welte
Gesendet: Montag, 5. April 2010 03:25
An: baseband-devel(a)lists.osmocom.org
Betreff: Developer Meeting in Berlin / 2010-04-10
Hi all!
Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin.
This is mainly for me to get an idea where we are (compared to before my
holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog.
I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system.
I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join!
Cheers,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi,
the current state of coding can be seen in the
src/host/gsm48-andreas/README file of GIT. as noted there, the process
of mobility management and call control is completed. this does not mean
that it is compiling and working. als debugging has to be completed. the
next step would be to follow the compiler errors step by step until all
missing and wrong symbols are found and fixed. i will do that later.
also the radio ressource is at a point where i like to start integrating
it into the layer23 application. today i checked out how the system
informations are received and how to send a random access burst. please
check out the issues about that at src/host/gsm48-andreas/issues.txt in
the GIT.
i must note that layer3.c and rslms.c is not needed in my case, since it
is part of gsm48_rr.c
in order to integrate it, i would like to open a new branch, since there
are many other existing files to be expanded. (new structures to header
files... see extra.c and extra.h) there must also be a way to get all
the changes in the master branch merged to the new branch, so i can
react on changes of master branch. i am not that familiar with git, so
is there any advice except cherry-picking all the time? or maybe there
is a better way of doing that?
andreas
i managed to get hello_world working on my c121, connected through a
pl2303 usb/serial cable to my macbookpro.
but found that the connection is extremely noisy.
often the movement of me putting down the phone on the table is enough
to break the upload.
is that a common problem with these headphone/serial cable plugs?
for the serial device i can use /dev/cu.PL2303-0000201A
or /dev/tty.PL2303-0000201A
but when using the '/dev/tty...' variant, i have to add this to osmocon.c
diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
index f934dd7..b361eb1 100644
--- a/src/host/osmocon/osmocon.c
+++ b/src/host/osmocon/osmocon.c
@@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
/* hardware flow control off */
options.c_cflag &= ~CRTSCTS;
+ /* ignore modem status lines */
+ options.c_cflag |= CLOCAL;
+
/* software flow control off */
options.c_iflag &= ~(IXON | IXOFF | IXANY);
=============================
willem
Hi all!
Since I'm returning from holidays in two days, I think it's a good idea
(for those who are in/around Berlin) to meet again at CCC Berlin.
This is mainly for me to get an idea where we are (compared to before my
holidas) and how we proceed. Especially the loader seems to have made
progress, as far as I can tell from casual reading of the commitlog.
I'm also curious to see what's happening on the battery charger, sim
card reader (and other) parts of the system.
I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in
joining, feel free to join!
Cheers,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi,
today i will finally (begin to) structure the message handling in my
current work on layer 3:
the message handling functions consist of:
- message cration
- message sending
- message en-queueing
- message de-queueing
i deal with interfaces (SAP):
- between application and call control (MNCC-SAP)
- between call controll and mobility management (MMCC-SAP)
- between supplementary services protocol and mobility management
(MMSS-SAP)
- between sms protocol and mobility management (MMSMS-SAP)
- between mobility management and radio ressource (RR-SAP)
- between radio ressource and layer 2 / layer 1 (let's call it
RSLms-SAP)
additionally there are interfaces:
- between application and mobility management
- between application and PLMN search
- to the sim card
- to the application
- ...
here is what i think the messages should look like. please correct me if
i am wrong or if you have suggestions:
MNCC-SAP:
<gsm48_mncc structure>
MMCC-SAP, MMSS-SAP, MMSMS-SAP:
<gsm48_mmxx structure>[<L3 message*>]
RR-SAP:
<gsm48_rr structure>[<L3 message*>]
RSL-SAP:
<abis_rsl_rll_hdr structure>[<L3 message*>]
* the layer 3 message consists of the gsm48_hdr structure + additional
information elements.
if a layer 3 message moves from call control down to RSL and even lower,
the inter-layer headers are pulled and pushed. additionally there are
pointers to the beginning of the headers inside the message:
- l1h
- l2h
- l3h
- layer 4 headers
- layer 5 header
the inter-layer messages (MMxx-SAP and RR-SAP) will have no pointer to
the message structures. i think they also should not have them, since
they have fixed length and are pushed at the time they are sent, and
pulled at the time they are received.
any suggestions?
andreas
Hi,
First off, thank the community--OsmocomBB for launching and then sharing the
development of mobile protocol stack first.
As we can understand, the current mailing list has been acting as the
primary way of communicating between one another on the project basis.
For these quick questions as well as immediate discussions, however, most
likely there should be yet another way to complement, like irc on the
freenode.
Or, for the above issue you guys out there have other ways to solve, eh? If
so, please take me into the circle as well, just because I have too many
questions to ask. :)
Thanks.
Best Regards,
Samuel
> but found that the connection is extremely noisy.
> often the movement of me putting down the phone on the table is enough
> to break the upload.
i had a similar problem with an unconnected input pin which caused a
reset of a microcontroller, just by moving some centimeters in a
distance of one meter. check if you have left unconnected input pins on
your USB converter. what about hardware flow control input? (RTS/CTR)
andreas
hi harald,
>> must random value in chan_request change on every resend or only on
>> every RR establishment? (currently it changes on every RR
>> establishment only.)
>
>as far as I know, it has to change on every retransmission. Dieter is
>probably the person who knows all RACH aspects in detail, maybe he can
>comment on this.
from the specs it is quite clear that every access burst has different
random number when resending. but how does the network know if the burst
is from the same phone but retransmitted? in case of poor uplink many
bursts may be resent. will the network allocate a channel for every
burst received and waits for timeout? (if this is the case, emergency
calls could quickly 'evacuate' the cell.)
>> OpenBSC: if tx-msg fails during process, the msg must be freed to
>> avoid memory leak.
>
>I don't understand, can you please explain this further?
it is something to remind me that there are memory leak problems. in
some functions of gsm_04_08.c there are messages allocated at the
beginning and sent at the end. sometimes during processing, the function
returns due to error conditions, but the message is not freed before
return. i will check that later together with my new code.
as far as i can see right now, it just happens in gsm48_cc_tx_setup().
regards,
andreas
Hello Andreas,
On Mon, 29 Mar 2010 13:39:21 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> from the specs it is quite clear that every access burst has different
> random number when resending. but how does the network know if the burst
> is from the same phone but retransmitted? in case of poor uplink many
> bursts may be resent. will the network allocate a channel for every
> burst received and waits for timeout? (if this is the case, emergency
> calls could quickly 'evacuate' the cell.)
It does not even need a poor uplink. I experience this behaviour for example
with OpenBSC and the nanoBTS. If the "Immediate Assignment" is not sent
fast enough, a retransmitted RACH burst will allocate another channel
(the timeout for releasing an unused channel is around 2 to 5 seconds in
"real" GSM networks). The maximum number of the retransmitted RACH burst
is controlled by a parameter in the SYSTEM INFORMATION messages (there
are several parameters which control the RACH transmission behaviour).
Of course a "bad phone" can ignore those parameters and a DoS attack
with continuous RACH bursts works quite well because the BTS or
network does not know from which phone the burst come from.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Christian,
On Mon, 29 Mar 2010 13:27:31 +0200, "Christian Vogel" <vogelchr(a)vogel.cx> wrote:
>
> I'm using a self-made cable consisting of a known good FT232R
> converter @ 3.3V and a cut off headset cable (that also worked
> flawlessly without any noise on another mobile phone before). My C123
> also looks pristine. I manage to upload and run hello world
> successfully in maybe one out of ten attempts, often have to remove
> the battery because the phone just gets stuck. So I have ordered a new
> cable from Akku-King as suggested on the Wiki.
My experience: I work under Windows with Cygwin so the OS internals
how the serial port is handled are (totally) different than Linux.
With the non-blocking variant of "osmocon" it was nearly impossible
to download the code to the phone in a reliable way. So I had to apply
an ugly hack to my version which basically switches the serial connection
to "blocking mode" during the download phase. This way it works rather
reliable here (regardless of using a "real" RS232 port or an USB to serial
converter).
So you might experience the same problem instead of a bad cable. You
can try the attached patch to "osmocom.c". The patch is not for the
latest GIT version, however it should be quite easy to apply it to
the current on. Again, its an ugly hack, but it works for me.
Best regards,
Dieter
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Willem,
On Mon, 29 Mar 2010 12:39:35 +0200, "willem" <itsme(a)xs4all.nl> wrote:
>
> but found that the connection is extremely noisy.
> often the movement of me putting down the phone on the table is enough
> to break the upload.
> is that a common problem with these headphone/serial cable plugs?
Hello Harald,
On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> as far as I know, it has to change on every retransmission. Dieter is
> probably the person who knows all RACH aspects in detail, maybe he can
> comment on this.
According to the specification the random value has to change on every
transmission:
a random reference which is drawn randomly from a uniform probability
distribution for every new transmission.
In the TSM30 firmware this is done by having a table with random values
and an index into the table which is initialised to a random value when
the Immediate Assignment Procedure is started and incremented with every
random number taken for a retransmission. The table has 32 values because
the random reference is not larger than 5 bits.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi Andreas,
some comments regarding your issues.txt:
> must random value in chan_request change on every resend or only on
> every RR establishment? (currently it changes on every RR
> establishment only.)
as far as I know, it has to change on every retransmission. Dieter is
probably the person who knows all RACH aspects in detail, maybe he can
comment on this.
> must be expanded: struct osmocom_ms:
no problem here, expand it how you see fit. I just generally prefer
caller-allocated structures to callee-allocated ones, and I'd like to
use static allocation whenever possible. So if there's only one 'struct
rrlayer' per ms, then we should simply include 'struct rrlayer' as
sub-structure of 'struct osmocom_ms', rather than having two structures
and pointers between them.
> OpenBSC: if tx-msg fails during process, the msg must be freed to
> avoid memory leak.
I don't understand, can you please explain this further?
> random acces via RSL?
I think we simply add some new / non-standard primitives, as it does not
have any notion of RACH bursts.
It might also be possible to encode it as UNIT DATA REQUEST for channel
(chan_nr) RACH (CCCH uplink), but then we still cannot specify details
like at which frame number, etc. From what I can see, your
RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement
we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom
RSLms message and nothing specified in the original RSLms spec.
Cheers,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
I started to play around with osmocon, but unfortunately my serial
cable (a FTDI232RL module from Sparkfun connected to the 2.5mm plug,
this one is set to 3v3 and worked flawlessly for several projects!)
seems to be quite unreliable in the host -> handset direction.
But to not procrastinate, I did some cleanup in osmocon to escape
non-printable output and added new "-c" option to start straight into
HDLC-mode without uploading any firmware to the mobile.
Are those kinds of mostly cosmetic patches appreciated or considered
unnecessary?
Chris
Hi,
what's currently the recommended toolchain for bb-osmocom?
The wiki says on http://bb.osmocom.org/trac/wiki/AreasOfWork
that most people are using gcc 4.0.2 from http://gnuarm.com/
but the binary there is only for x86_64 which I don't use.
So, as I've got to build from source, I'm going to download
the latest binutils/gcc/newlib(?) for that. Is it a good idea,
or are there known problems with gcc binutils 2.20.1/gcc 4.4.3?
Greetings,
Chris
Hi!
It seems we're loosing serial characters on their way from the (Linux)
PC to the phone.
I think I've seen this at some point in the past, but now I'm seeing it
constantly.
Let's assume we're trying to send the following sequence of bytes from
the PC side to the phone in one of the HLDC connections:
> send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
> 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
> 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
what we actually get from the sercomm callback on the phone is:
> l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
> 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a
> 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
as you can see, there is a '00 01' missing between the '00' and the '02'.
Interestingly, putting a usleep(10000) after every serial write does not
solve the problem, so it is not timing related. We don't get any UART
overflows on the calypso, either.
If I change the data pattern, then the first bytes are transmitted fine,
but as soon as there is one 00 bytes, two characters are missing from
the stream.
If I strace osmocon, it is clear that we write every character,
including the null-bytes, and all of the writes are successfully.
I've again looked at (and played with) the termios settings, but could
not find any problem (nor solution).
It's also not the sercomm layer that is loosing bytes, as I the
characters appear already lost when printing them from within the
calypso UART driver, as you can see here:
getchar_nb(1) = 7e // flag character
getchar_nb(1) = 05 // hdlc
getchar_nb(1) = 03 // hdlc
getchar_nb(1) = 0a // l1ctl_hdr (undefined msg_type 10)
getchar_nb(1) = 00 // padding
getchar_nb(1) = 02 // here should be 00, 01, 02...
getchar_nb(1) = 03
getchar_nb(1) = 04
getchar_nb(1) = 05
[...]
Any ideas? It's really strange and I don't really know what else to do.
I'm quite sure our binaries contain multiple successive null-bytes and
their download is working great...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi *,
i have an Motorola C123 without a battery and without a charger.
Can someone told me pinout of the battery Connector so that I can connect a nokia battery?
Or can I use a 5v power supply and connect it to the charger port and the phone boots without a main battery?
Bjoern
-----
#- Björn Riemer
#- FOKUS - Fraunhofer Institute for Open Communication Systems
#- -Sensor Applications and Networks -
#- Kaiserin-Augusta-Allee 31
#- 10589 Berlin, Germany
#- phone: +49 30 3463-7747
#- fax: +49 30 3463-8000
#- email: bjoern.riemer(a)fokus.fraunhofer.de <mailto:bjoern.riemer@fokus.fraunhofer.de>
#- http://www.fokus.fraunhofer.de <http://www.fokus.fraunhofer.de>
attached is a patch with several minor fixes:
added missing param in call to gsm48_rx_bcch.
added 'extern' in .h files for declarations of rsl_rlm_cause_strs and
target_board.
added several 'const' for strings.
removed useless 'bufptr,' from hexdump.
willem
Hello,
I'm very new here and I wanted to ask if you already choose an OS? On
the website I read that you don't want to use FreeRTOS. Is this
information still up to date? Which RTOS u want to use instead? I have
found a small summary of potential candidates at wikipedia:
http://en.wikipedia.org/wiki/List_of_real-time_operating_systems
the best candidate seems to be BeRTOS, but i think it could be a little
bit too much (e.g. it has a complete graphics subsystem).
Regards
Arne
This is a Mailman mailing list bounce action notice:
List: baseband-devel
Member: osmocon(a)ngolde.de
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
Hello Erik,
On Fri, 19 Mar 2010 09:51:48 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote:
>
> Yes. Mine has special US Tracfone firmware which seems to have a
> particularly evil unlock scheme. Cutting one of the balls in the BGA
> seems the way to do it..
I had a quick look at the bootloader from a dumped Tracfone C139
firmware. Its nearly the same the Osmocom loader supports, however
this special bootloader checks a flag in flash memory to decide wether
to allow RAM download or not. If it is disabled, only the FTMTOOL
check is done and no RAM download at the boot stage is possible.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
today my serial cable finally arrived. As in the meantime a driver for
the C155 display was added I am searching for new things I might be able
to do.
The AreasOfWork lists under Build System
"we need a clean/known base as a compiler"
As a LFS user I'm used to compiling my own software and as I did for the
toolchain which currently consists of
binutils-2.19.1
gcc-4.3.4
newlib-1.18.0
and as I now have the cable, I can confirm that it works.
The instructions in the support section of gnuarm.com work well if you
have the needed libs (gmp, mpfr, ...) and not picked a broken version of
binutils or others.
So my questions are:
(1) Is this still a todo or did someone work on it?
(2) What needs to be done?
Thanks for all your work, this is amazing,
Florian Tobias Schandinat
Hello Erik,
On Fri, 19 Mar 2010 07:42:06 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote:
>
> I did some more research and it seems even the unlocking people are
> having the same problems here. So I will just wait for my other phone.
I do have one C139 here, it works with the "board/compal_e88/hello_world.bin"
firmware and the "-m c123xor" option for "osmocon", however without the
display working (its a different display). If I boot the normal phone
firmware, I also see some output and have the same "AT" behaviour you
reported.
But maybe there are different versions of the C139 so that some work and
others don't.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi
I just got my cable and am trying to download any code into a C139
(tracfone software, bought from usa on ebay).
This is what I get:
$ ./osmocon -m c123 -p /dev/ttyS2 compal_dump.bin
waiting for data
got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c
Received FTMTOOL from phone, ramolader has aborted
got 1 bytes from modem, data looks like: 65
got 1 bytes from modem, data looks like: 72
got 1 bytes from modem, data looks like: 72
got 1 bytes from modem, data looks like: 6f
got 1 bytes from modem, data looks like: 72
^C
Hello Andreas,
On Thu, 18 Mar 2010 10:41:32 +0100, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i prefer the CNC machine solution. it looks pretty easy to me. in my
> example white = fully cut out. black = no cut, light gray = more
> deep , dark gray = less deep.
Looks good, do you have access to a CNC machine and what costs would
you expect for a prototype ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I've been slowly working on the DSP code for some time now and I
tought I'd post a status here in case other people are interested.
The ultimate point of this is to add support for things the DSP isn't
supposed to do. Like receiving the raw demodulated data without the
deciphering / fire code / whatever. Or dealing with raw speech data
... sending other type of burts like SCH / FCCH, or receiving other
type of bursts like RACH, ...
The DSP ROM dumper has been present for a while but there was no way
to really use the output efficiently.
For that, I've written a parser that takes the console log output and
converts it into a COFF file that you can load in your favorite
disassembler.
I've been working with IDA 5.6 mostly and I made several enhancement
to it to support the calypso better (the tms320c54 module is part of
the SDK and can be modded and recompiled) :
- Add support for memory mappings so that the same memory zone can
'appear' at several place in the address space (to handle data & code
overlay)
- Fix the section handling when loading a file:
. to set XPC properly,
. to not override section name
. to support more than 2 sections
- Fix a bug in cross reference detection when dealing with section
having selectors != 0
- Add stub support for the type system. This allows loading of a .h
header file with the NDB structure definition
- Add definition for the IO ports so that they are symbolically displayed
Here's a sample results of what it looks like now (without much manual
fixups, just loading the files and declaring a couple addresses as
being structures) :
http://www.246tnt.com/files/calypso_dsp_ida_sample.png
It becomes clear what function does what :)
I'll try to push a maximum in my dsp branch tomorrow. I can't put the
IDA processor module modification because even just the patch contains
some hex-rays code, so I guess I'll have to ask them permission on a
case by case basis to distribute it. (just ask me privately and we'll
work it out)
Cheers,
Sylvain
Hello,
Just a note about the RS-232 cable from Dealextreme:
http://www.dealextreme.com/details.dx/sku.14664
This is a direct connection cable, this means that there is no
level-converter between the phone and the RS-232 port from the
PC. Despending on the RS-232 port of the PC, I would expect that
this can/will damage the phone. I have one of those cables here
and can confirm that there is no level-converter in between.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sebastien,
On Thu, 18 Mar 2010 12:17:18 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> The SIM obviously relies on a filesystem. Some files are defined as
> mandatory in TS11.11, so I will include them, but their size is not always
> fixed. I'm opening this thread to define this kind of information.
Maybe useful:
https://sites.google.com/site/savolabs/Home/tools
Its about a tool (SIMbrush) to extract all EFs from a SIM. Besides the
source code there is also a PDF file with the results from scanning a
standard SIM, it contains the file size for the EFs of the scanned SIM.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
I'm making progress on the SIM/Filesystem applet. Data access commands are
working, I'm now working on writing commands that send replies formatted as
defined in TS 11.11 instead of FCI responses.
I need input from you: I'm only a "smart card" guy, I can do "whatever is
needed", but I need to define *what* is needed with you. I know especially
nothing about GSM itself except that the MS talks with the SIM to manage
cryptography, store SMS and phonebooks entries, etc.
The SIM obviously relies on a filesystem. Some files are defined as
mandatory in TS11.11, so I will include them, but their size is not always
fixed. I'm opening this thread to define this kind of information.
-what should be the N value for files whose size is defined by "3*N, N>=4"?
-what optional files will be needed when the layer 2-3 will be ready to talk
with the SIM?
I let you read the TS11.11 spec to make your choice.
Thanks,
Sebastien
