Re: Fun with IMEI (was testing the free calypso software)
=?UTF-8?B?S2FpIEzDvGtl?= wrote:
> thanks to the recent activies I also thought about IMEI yesterday
> evening and it was fun that other's also did. Setting IMEI would still
> be a nice feature.
A general purpose FFS editing kit for GTA01/02 modems, which will
include the ability to set the IMEISV to whatever you like, is coming
soon - be patient. (Or if you are impatient, feel free to follow the
project as it happens in the Mercurial repository on Bitbucket.)
Yes, I said IMEISV, not just IMEI - if you don't know the difference,
read it up on Wikipedia etc. Even though the file in TI's device file
system is named /pcm/IMEI (at least on older modems like Om's which
don't use the so-called "IMEI protection"), the number it actually
stores is the IMEISV. The file is (or should be) exactly 8 bytes long,
storing the 16 digits of IMEISV, two digits per byte, and the GSM
protocol stack into which this number is fed (by way of a function
called cl_get_imeisv(), grep for it in the leo2moko source) treats the
last two digits (stored in the last byte) as the SV field, not the
Luhn check digit.
That being said, it looks like both Openmoko/FIC and Pirelli/Foxconn
set the SV field of their factory-programmed IMEISV numbers to x0,
where x is the Luhn check digit for the IMEI part, such that one can
"cheat": take the 16-digit IMEISV, drop the last digit, and treat the
remaining 15 digits as if they were the "classic" IMEI. (Such
"cheating" is what my current leo2moko implementation of the AT+CGSN
command does - I made it match Om's functionality before I realized
that /pcm/IMEI is really IMEISV.) A more reliable way to retrieve the
complete IMEI information on any TI-based modem is to issue an ATD*#06#
command: it will return a 17-digit number consisting of the 14 digits
of the IMEI proper, the Luhn check digit, and the 2 SV digits.
> In addition it would be interessting for me (in times of surveillance)
> whether silent sms (stealth ping) could be recognized and a report be
> dropped to the mobile phone. Also the change to non-encrypted transfer
> would be a similar event which might occure due to an IMSI catcher, so
> generating a message (SMS?) warning the user would be helpful.
Before we can implement the alerting functions you are asking for, we
need to liberate the GSM protocol stack first. The current leo2moko
fw has this protocol stack in a bunch of binary object libraries, as
that's what TI provided in the TCS211 ("Leonardo") deliverable. Full
source forms of closely related versions are available through the
TSM30 and LoCosto leaks though, the latter being more promising - hence
the current FC project plan is to try lifting the g23m* code layers
from the LoCosto version, and see what we get. But there is a bunch
of other preparatory work that needs to get done before we get to that
point.
> Also: Could the gsm module be made working without a SIM, i.e. just by
> providing the necessary values like IMSI and Ki?
Sure thing, and OsmocomBB already supports such usage. But where are
you going to get a Ki that is recognized as valid by the GSM network
you wish to use? And what would the corresponding phone number
(MSISDN) be?
VLR,
SF
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Fun with IMEI (was testing the free calypso software)
El día Tuesday, February 04, 2014 a las 08:34:00PM +0100, Kai Lüke escribió: > > Also the change to non-encrypted transfer > would be a similar event which might occure due to an IMSI catcher, so > generating a message (SMS?) warning the user would be helpful. For this see the thread in our mailing list with the Subject: Subject: FR && non encrypted calls in July 2011. I.e. the FR knows perfectly well if the call is ciphered or not. We only should bring this information to the GUI with a question: Call not ciphered, should we continue yes or no? matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fun with IMEI (was testing the free calypso software)
Hello community,
thanks to the recent activies I also thought about IMEI yesterday
evening and it was fun that other's also did. Setting IMEI would still
be a nice feature.
In addition it would be interessting for me (in times of surveillance)
whether silent sms (stealth ping) could be recognized and a report be
dropped to the mobile phone. Also the change to non-encrypted transfer
would be a similar event which might occure due to an IMSI catcher, so
generating a message (SMS?) warning the user would be helpful.
Also: Could the gsm module be made working without a SIM, i.e. just by
providing the necessary values like IMSI and Ki? As far as I don't know
the issue well, it's just a question ;)
Regards,
Kai
Am 04.02.2014 01:23, schrieb Michael Spacefalcon:
> Norayr Chilingarian wrote:
>
>> Does anyone know what will happen in a cellular network where there is
>> more than one device has the same IMEI. In other words, if we all
>> could change our IMEI numbers, and use one imaginary number, are there
>> technical reasons for network to not work.
> joerg Reisenweber responded:
>
> : no technical but organizational. Usually that IMEI gets an instant ban, and
> : a fat bold red alarm logline in carrier's network logs.
>
> Yup, if all of us were to use the same IMEI number, it would be far
> too easy for our enemies to ban that one single number.
>
>> I mean, MAC address is used on a physical layer, so if two network
>> cards connected to the same switch have same MAC adresses, network
>> won't work. I guess switch will down both ports connected to those
>> devices.
> The analogy between IMEIs and Ethernet MAC addresses is a good one
> from a manufacturing/management perspective, but not in terms of
> network protocol usage. Unlike MAC addresses, IMEIs are not used for
> any kind of addressing or routing anywhere in the network, only as a
> "management" identifier that is unnecessary in the strict technical
> sense.
>
> But from the perspective of a device manufacturer (which I will become
> soon, hopefully), IMEIs are just like Ethernet MAC addresses: the
> nominal requirement is that each be world-unique for all time (a rule
> that gets broken in reality with both MAC addresses and IMEIs), a
> manufacturer has to buy a range (supposedly "fresh" and unused) from a
> central registry, and then number individual produced units out of
> that range.
>
>> But I don't know how IMEI's work. Are they technically necessary so
>> that 3G/gsm network can be operational, or they are only used to
>> identify (and track) customers by devices?
> The latter.
>
> Before everyone starts changing their IMEIs just for the heck of it,
> let's analyze *rationally* how tracking works - or rather, what is the
> total set of data elements available to carriers (and their gov't
> partners etc) for tracking users, and how these data elements inter-
> relate.
>
> If you like maintaining a long-term-constant phone number at which
> your family and friends can reach you (i.e., the whole purpose for
> having a cellphone, at least for me), and you have a long-term-stable
> SIM card associated with that long-term-constant phone number, then it
> doesn't really matter if your IMEI is also constant or if you send the
> output of a PRNG (or even a TRNG) to the network as your IMEISV every
> time your phone/modem fw does the "register" operation. The constant
> SIM card with its IMSI, as well as the associated MSISDN (phone number
> for your family and friends to call you at), is what tells the network
> that "you" are still the same "you", no matter what device you use or
> what IMEISV it transmits. Yes, you can deregister from the network,
> then re-register with a different IMEI, making it look like you turned
> your phone off, moved your SIM card to another phone, then came back
> online with the latter - but what would be the point?
>
> Instead, there are only two scenarios I can think of in which it would
> make sense to change the IMEI of a GSM device:
>
> 1. If you really want to "disappear w/o trace", such that you discard
>your old SIM, get a new SIM (prepaid, presumably) with a different
>phone number (and deliberately make yourself unreachable at your
>old one), and you want to make it look like the user of the new SIM
>is a different person from the user of the old SIM - in this case
>the same IMEI would indeed give you away, so you might want to
>change it in this case.
>
> If the above applies to you (and it does *not* apply to me, as changing
> phone numbers constantly would defeat the whole purpose of a cellphone
> for me), then you need to be careful to change your IMEI *at exactly
> the same time* when you change your SIM - if there is any time skew
> between these two changes, such that a network sees {old IMEI, new SIM}
> or {new IMEI, old SIM} at any time, even just once, your anonymity
> effort will be instantly brought to naught! If you want to do this, I
> would recommend pulling your old S
Fun with IMEI (was testing the free calypso software)
Norayr Chilingarian wrote:
> Does anyone know what will happen in a cellular network where there is
> more than one device has the same IMEI. In other words, if we all
> could change our IMEI numbers, and use one imaginary number, are there
> technical reasons for network to not work.
joerg Reisenweber responded:
: no technical but organizational. Usually that IMEI gets an instant ban, and
: a fat bold red alarm logline in carrier's network logs.
Yup, if all of us were to use the same IMEI number, it would be far
too easy for our enemies to ban that one single number.
> I mean, MAC address is used on a physical layer, so if two network
> cards connected to the same switch have same MAC adresses, network
> won't work. I guess switch will down both ports connected to those
> devices.
The analogy between IMEIs and Ethernet MAC addresses is a good one
from a manufacturing/management perspective, but not in terms of
network protocol usage. Unlike MAC addresses, IMEIs are not used for
any kind of addressing or routing anywhere in the network, only as a
"management" identifier that is unnecessary in the strict technical
sense.
But from the perspective of a device manufacturer (which I will become
soon, hopefully), IMEIs are just like Ethernet MAC addresses: the
nominal requirement is that each be world-unique for all time (a rule
that gets broken in reality with both MAC addresses and IMEIs), a
manufacturer has to buy a range (supposedly "fresh" and unused) from a
central registry, and then number individual produced units out of
that range.
> But I don't know how IMEI's work. Are they technically necessary so
> that 3G/gsm network can be operational, or they are only used to
> identify (and track) customers by devices?
The latter.
Before everyone starts changing their IMEIs just for the heck of it,
let's analyze *rationally* how tracking works - or rather, what is the
total set of data elements available to carriers (and their gov't
partners etc) for tracking users, and how these data elements inter-
relate.
If you like maintaining a long-term-constant phone number at which
your family and friends can reach you (i.e., the whole purpose for
having a cellphone, at least for me), and you have a long-term-stable
SIM card associated with that long-term-constant phone number, then it
doesn't really matter if your IMEI is also constant or if you send the
output of a PRNG (or even a TRNG) to the network as your IMEISV every
time your phone/modem fw does the "register" operation. The constant
SIM card with its IMSI, as well as the associated MSISDN (phone number
for your family and friends to call you at), is what tells the network
that "you" are still the same "you", no matter what device you use or
what IMEISV it transmits. Yes, you can deregister from the network,
then re-register with a different IMEI, making it look like you turned
your phone off, moved your SIM card to another phone, then came back
online with the latter - but what would be the point?
Instead, there are only two scenarios I can think of in which it would
make sense to change the IMEI of a GSM device:
1. If you really want to "disappear w/o trace", such that you discard
your old SIM, get a new SIM (prepaid, presumably) with a different
phone number (and deliberately make yourself unreachable at your
old one), and you want to make it look like the user of the new SIM
is a different person from the user of the old SIM - in this case
the same IMEI would indeed give you away, so you might want to
change it in this case.
If the above applies to you (and it does *not* apply to me, as changing
phone numbers constantly would defeat the whole purpose of a cellphone
for me), then you need to be careful to change your IMEI *at exactly
the same time* when you change your SIM - if there is any time skew
between these two changes, such that a network sees {old IMEI, new SIM}
or {new IMEI, old SIM} at any time, even just once, your anonymity
effort will be instantly brought to naught! If you want to do this, I
would recommend pulling your old SIM out first, throwing it away, then
doing the IMEI changing operation on the SIM-less modem, and then
finally inserting your new SIM.
2. Changing one's IMEI may be necessary if your "legitimate" IMEI from
the manufacturer of your GSM device has been wrongfully banned or
blocked by some GSM network you wish to use, and you need to use
some non-blocked IMEI in order to get on the network.
The wrongful ban scenario is particularly frightening when applied to
whole classes of devices, rather than individual units. The first 8
digits of the IMEI comprise the Type Allocation Code (TAC), which is
supposed to be allocated per each device type. Hence if all
manufacturers involved played by the rules (of which I have no
knowledge), then every IMEI beginning with 35278901 is supposed to be
a Pirelli DP-L10, every IMEI beginning with 35465101 is supposed to be
an Openmoko GTA02, and so
Re: testing the free calypso software
On Mon 03 February 2014 21:42:38 Norayr Chilingarian wrote: > Does anyone know what will happen in a cellular network where there is > more than one device has the same IMEI. In other words, if we all > could change our IMEI numbers, and use one imaginary number, are there > technical reasons for network to not work. no technical but organizational. Usually that IMEI gets an instant ban, and a fat bold red alarm logline in carrier's network logs. cheers jOERG -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
Does anyone know what will happen in a cellular network where there is more than one device has the same IMEI. In other words, if we all could change our IMEI numbers, and use one imaginary number, are there technical reasons for network to not work. I mean, MAC address is used on a physical layer, so if two network cards connected to the same switch have same MAC adresses, network won't work. I guess switch will down both ports connected to those devices. But I don't know how IMEI's work. Are they technically necessary so that 3G/gsm network can be operational, or they are only used to identify (and track) customers by devices? I am just curious. 01/29/14 12:39 -ում, Michael Spacefalcon-ը գրել է: > And yes, there is that file named /pcm/IMEI in there, with quite > obvious content. Use cat -h as it's a binary file, two IMEI > digits per byte, using the least significant nibble first - so it > looks counter-intuitive in a hex dump. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
I've now prepared a second distro that can be used to flash the calypso with either of the two methods using Michael's loadtool program. This distro uses QTmoko as a base and includes the loadtool-r2 release and both the leo2moko-r1 and moko11 firmware. As such, you do not need an unlock cable (although you can use this distro in conjunction with one) and you do not need to compile anything on your PC or freerunner. Like my initial offering, this distro runs from sdcard and boots from the NOR menu, so you do not need to disturb anything you have in NAND. Full write up at http://winterveldt.co.za/leo2moko-p2.html My thanks to Michael for his efforts so far to free the calypso and also to Radek for his continued work on QTmoko. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
Norayr Chilingarian wrote:
> If someone has no backup of calibration data, can she use calibration
> data from other phone?
> Then we can send our data to that person. Or it won't work this way?
> I probably don't understand it well.
joerg Reisenweber followed up:
> Not recommended and not entirely correct procedure but nevertheless should
> sort of work, yes. You might want to edit the IMEI to what yours been, before
> (or after) you flash that alien calib data.
I still have a lot of learning ahead of me in this department, but per
my current understanding, the purpose of RF calibration is to measure
those physical variations which exist from one produced unit to the
next, and to record these measurements (or some values derived from
the measurements) in per-device non-volatile memory, such that the
modem firmware can then take account of and compensate for these per-
device differences. I'm guessing it has something to do with non-
linearity in the amplifiers, process variations in the ADCs and DACs,
temperature sensitivities etc. This document from TI attempts to
explain some of it:
ftp://ftp.ifctf.org/pub/GSM/Calypso/rf_calibration.pdf
So my current understanding is that at least some of the calibration
values will differ from one unit to the next, and I reason that taking
the values from one unit and using them on a different unit may cause
some poor RF performance, or out-of-spec operation in terms of Tx
power levels perhaps. I have no way of knowing just how much
difference there is between one GTA02 and the next, and hence what
would the magnitude of ill effects from a calibration transplant be.
A good experiment would be to compare the calibration values (properly
programmed at the factory, presumably) read out of different GTA02
units. The flash dump from my GTA02 can be found here:
ftp://ftp.ifctf.org/pub/GSM/GTA02/flashdump.bin
I made that dump from my GTA02 back in 2013-04, and put it on the FTP
site in 2013-07, long before the recent project breakthroughs. The
first 0x225594 bytes of that flash image (just under 2.25 MiB) contain
the moko10 fw image (what my FR came with); the interesting part (the
FFS) starts at offset 0x38.
Using the new tiffs/mokoffs tools I just wrote (get them from the Hg
repository on Bitbucket or wait for my coming-soon tarball release),
we can examine the content in this FFS image. Let's start with the
basic vital stats:
$ mokoffs -f flashdump.bin blkhdr
Block 0: age , type/status AB
Block 1: age , type/status BD
Block 2: age , type/status BD
Block 3: age , type/status BD
Block 4: age , type/status BD
Block 5: age , type/status BD
Block 6: age , type/status BF
$ mokoffs -f flashdump.bin fsinfo
Active inode block (AB) is block #0
Root inode is #1
Root inode (format) name: /ffs-root
(mokoffs is a trivial wrapper around tiffs that spares the user from
having to specify the 64x7 FFS organization argument every time, and
-f means that one is looking at a complete flash dump, rather than
just the FFS sectors - hence the tool needs to go to offset 0x38.)
Listing the actual content is easy too:
$ mokoffs -f flashdump.bin ls
fr4096 /.journal
d /gsm
d /gsm/rf
d /gsm/rf/tx
f 512 /gsm/rf/tx/ramps.900
f 128 /gsm/rf/tx/levels.900
f 128 /gsm/rf/tx/calchan.900
f 512 /gsm/rf/tx/ramps.1800
f 128 /gsm/rf/tx/levels.1800
f 128 /gsm/rf/tx/calchan.1800
f 512 /gsm/rf/tx/ramps.850
f 128 /gsm/rf/tx/levels.850
f 128 /gsm/rf/tx/calchan.850
f 512 /gsm/rf/tx/ramps.1900
f 128 /gsm/rf/tx/levels.1900
f 128 /gsm/rf/tx/calchan.1900
d /gsm/rf/rx
f 40 /gsm/rf/rx/calchan.900
f8 /gsm/rf/rx/agcparams.900
f 40 /gsm/rf/rx/calchan.1800
f8 /gsm/rf/rx/agcparams.1800
f 40 /gsm/rf/rx/calchan.850
f8 /gsm/rf/rx/agcparams.850
f 40 /gsm/rf/rx/calchan.1900
f8 /gsm/rf/rx/agcparams.1900
f2 /gsm/rf/afcdac
f2 /gsm/rf/stdmap
f 24 /gsm/rf/afcparams
d /gsm/com
f 16 /gsm/com/rfcap
d /gsm/l3
f 144 /gsm/l3/rr_white_list
f 256 /gsm/l3/rr_black_list
f 44 /gsm/l3/eplmn
d /gsm/cops
f 16 /gsm/cops/operimsi
d /pcm
f 12 /pcm/CGMI
f 13 /pcm/CGMM
f 14 /pcm/CGMR
f8 /pcm/IMEI
f9 /pcm/IMSI
f 23 /pcm/LRN
f 21 /pcm/LMN
f 22 /pcm/LDN
d /sys
d /mmi
d /vos
d /vos/vm
d /vos/vrm
d /vos/vrp
d /var
d /var/log
d /var/tst
d /var/dbg
f 3152 /var/dbg/dar
d /Test
f4 /Test/Teststate.bin
f 196 /Test/Production.bin
d /aud
f 164 /aud/para0.cfg
Most of the above should be self-explanatory; the numbers shown before
the pathname for files ('f' as opposed to 'd') are the lengths of each
file in bytes. The files containing the RF calibration values we are
currently discus
Re: testing the free calypso software
On Tue 28 January 2014 18:58:19 Norayr Chilingarian wrote: > 01/27/14 10:26 -ում, Michael Spacefalcon-ը գրել է: > > In the absolute worst case scenario imaginable, if someone does lose > > their RF calibration values and has no backup copy anywhere, you > > should be able to send your FR to some lab to get it recalibrated. I > > If someone has no backup of calibration data, can she use calibration > data from other phone? > Then we can send our data to that person. Or it won't work this way? > I probably don't understand it well. > Not recommended and not entirely correct procedure but nevertheless should sort of work, yes. You might want to edit the IMEI to what yours been, before (or after) you flash that alien calib data. /j -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
01/27/14 10:26 -ում, Michael Spacefalcon-ը գրել է: > Even in the case of the FFS with the RF calibration values etc, there > is absolutely no danger of corrupting this FFS if you issue loadtool > commands exactly per the instructions. Saving a backup copy of the > FFS sectors is a precaution just in case you erase or write to the > wrong part of the flash. If you have this backup saved, you can > always restore it. > > In the absolute worst case scenario imaginable, if someone does lose > their RF calibration values and has no backup copy anywhere, you > should be able to send your FR to some lab to get it recalibrated. I If someone has no backup of calibration data, can she use calibration data from other phone? Then we can send our data to that person. Or it won't work this way? I probably don't understand it well. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
[cut] > But I still think that it would be better for FreeCalypso to have its > own "identity" that is separate and independent from Openmoko, i.e., > its own mailing list, its own website (wikified or otherwise) etc. Hi Michael, I keep on reading news about free firmware you are working on here, but despite your hard work, I will not register to yet another ML just for this. FYI. -- Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
joerg Reisenweber wrote: > That's a bold misconception. OM wiki isn't censored, it just gets cleaned of > SPAM and obviously incorrect AND hazardous info, like e.g. somebody suggesting > to run wear tests against NAND to verify its formatting. But I still think that it would be better for FreeCalypso to have its own "identity" that is separate and independent from Openmoko, i.e., its own mailing list, its own website (wikified or otherwise) etc. As a result of my involvement on another mailing list (on a topic that is totally unrelated to mobile phones), I became aware of this document from the ISO Technical Committee on terminology: http://www.ucolick.org/~sla/leapsecs/ISOTC37toITURA.pdf Simply put, the authors of the above statement from ISO TC37 emphasize the importance of using terms which have a 1:1 mapping to the concepts they are meant to stand for, i.e., 1 concept = 1 term. As you and others have made it perfectly clear on numerous occasions, the term "Openmoko" was never meant to stand for the concept of "free (or open) GSM modem"; instead this term (according to you and other high-standing community members, which I obviously am not) stands for a different concept, namely that of "a free application processor with a black box modem attached as a peripheral". And because the name "Openmoko" rightfully belongs to you and your former boss Sean Moss- Pultz, it is not my place to try to change its meaning. (In fact, Dr. HNS is effectively invoking this term=concept equivalence of "Openmoko" = "free AP with a black box modem as a peripheral" when he asserts the legitimacy of his GTA04 product as a non-downgrade successor to Om products.) But I am working with a completely different concept, namely that of a free GSM device, be it a modem or a complete "dumbphone". And because it is an entirely different concept than that which is mapped by the term "Openmoko", by the principles of ISO TC37 my new concept calls for a new term for referring to it. Hence the name FreeCalypso was born: I came up with this name about this time last year, following exactly the line of reasoning I've just outlined, and my first public announcement of FreeCalypso was this one: http://lists.openmoko.org/pipermail/community/2013-February/068270.html The FreeCalypso project is very much in need of its own web/list home under the ifctf.org domain name, which currently features only an FTP site. My desire is to create a lists.ifctf.org host first, hosting Mailman mailing lists exactly like Openmoko and almost all FOSS projects and technical communities have nowadays - anything else would be seen as substandard, and therefore unattractive to me. A website for FreeCalypso (wikified or not) can be created later, but my first focus is on the lists host on which we can create a proper new mailing list for FreeCalypso. And because I already have my own physical "datacenter" on my own physical turf, I *will not* buy hosting from someone else who would ask me to agree to their TOS or AUP or the like - hence my only option is to use my own physical hardware. A SAS JBOD chassis is already on its way to me from ebay, already paid for; the drives are next - as soon as I gather the cash to buy 6 SAS drives of some non-laughable capacity (I refuse to use SATA, and I desire 6 drives to start with for a raidz2 ZFS configuration - I'll be running OpenSXCE), I will finally have the necessary hw, and will begin the setup/configuration work. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
Hi Giacomo To clarify, there are two methods. The method I describe requires a cable as you run loadtools on your PC. The method Norayr describes does not need a cable as loadtools is run on the freerunner. It was and is my intention to produce an sdcard distro that allows either method. The cable is not expensive though if you don't want to wait a month or so. As for risk - as has been said, if the worst comes to the worst, there are the two methods on the wiki to fall back on. I've flashed the calypso to leo2moko, back to moko11 and back to leo2moko again using the cable / loadtools on PC method. I'm so confident about this (with wheezy on the PC) that I even proceeded with an attempted flash by the other method *after* seeing loadtools report fail with the backup routine. I'd propose that as a good indicator - if you can't run the backup routine successfully, don't proceed with a flash attempt. It's likely my failure with the loadtools on freerunner / no cable method was because my sdcard distro has an ancient kernel. Obviously loadtools has not been widely tested yet, but I'd say there is zero risk with cable method and wheezy on the PC and I'd be very surprised if that does not apply to all recent and current versions of Gnu/Linux. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
On Mon 27 January 2014 19:26:19 Michael Spacefalcon wrote: > Giacomo 'giotti' Mariani wrote: > > By the way, I think that your work, with the right notes about being > > experimental and so on of course, should also be in the official wiki. > > As much as I would love to see it happen, I doubt that the powers > controlling that wiki will ever allow it. That's a bold misconception. OM wiki isn't censored, it just gets cleaned of SPAM and obviously incorrect AND hazardous info, like e.g. somebody suggesting to run wear tests against NAND to verify its formatting. /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
Giacomo 'giotti' Mariani wrote: > Hi David, Michael, all, > thanks a lot for your work, it is very emotional to see this > "little" piece of freedom rising! You're welcome. :-) > I'm still not brave enough to risk my only (I mean in all my life time > so far) mobile phone, but I will soon ;-) There is nothing at risk really - if the leo2moko firmware doesn't work for you for some reason, you can always revert to moko11, using either our flashing tools or the "official" moko11 flasher. Even in the case of the FFS with the RF calibration values etc, there is absolutely no danger of corrupting this FFS if you issue loadtool commands exactly per the instructions. Saving a backup copy of the FFS sectors is a precaution just in case you erase or write to the wrong part of the flash. If you have this backup saved, you can always restore it. In the absolute worst case scenario imaginable, if someone does lose their RF calibration values and has no backup copy anywhere, you should be able to send your FR to some lab to get it recalibrated. I don't offer such service currently because I haven't acquired the necessary RF test equipment and process knowledge yet, but when I start building my own Calypso phones, I will obviously need to get them calibrated, and once we have the knowledge and the setup to do it, Harhan Engineering Co. will also offer recalibration services to Freerunner users. > By the way, I think that your work, with the right notes about being > experimental and so on of course, should also be in the official wiki. As much as I would love to see it happen, I doubt that the powers controlling that wiki will ever allow it. > A small question about the procedure you describe: is the t191 cable > only needed to backup the "vital parts of the calypso memory" or also to > write the new firmware? Both if you use the uSD system which David just released; neither if you get FreeCalypso loadtools running on the Linux processor of your FR like Norayr did. Oh, and just to be clear as to exactly what the "vital parts of the calypso memory" in question are: the only entity that lives in the GSM modem's flash memory besides the firmware image (which is exactly the same in a device as it is on the web at the official download URL) is the flash file system, or FFS. The FFS in Openmoko's modems takes up exactly 448 KiB of flash space (64 KiB x 7); per TI's design it is structured like a UNIX file system (directory tree, forward-slash- separated pathnames, case-sensitive etc) and stores a bunch of things: * The modem's IMEI; * RF calibration values; * ID strings which say that your device is a "Neo1973 GTA02" made by "FIC/OpenMoko" - Om's late firmwares (moko10/11) appear to not use these strings from FFS (fw returns hard-coded strings instead), but my leo2moko fw returns the strings from FFS following TI's canon; * Some dynamic data written into the FFS (the fw always "mounts" the FFS with R/W access, TI's fw has no concept of a "read-only mount" for the FFS) during the operational lifetime of the modem: history of what SIM cards this modem saw, dialed/received/missed calls, and probably received SMS as well - I have yet to play with the latter. Just this weekend I wrote a new utility for examining FFS images read out of TI-based GSM devices (our beloved FR being one of them); this new tiffs utility (with mokoffs and pirffs wrappers) supercedes my earlier mpffs-* tools I wrote and released last summer. The new utility allows one to list and extract not only the "current" file content of the FFS (i.e., what one sees when "mounting" the file system normally), but also those files which have been logically deleted or overwritten, but not yet reclaimed, i.e., not truly gone. Hence the tool can be used to do forensics on Freerunner modems - I suspect many of you probably never thought about the modem's flash memory remembering the history of what SIM cards you had in there, what numbers you called or received calls from, and probably your SMS exchanges too... The just-described utility currently lives in the freecalypso-sw tree on Bitbucket: http://lists.openmoko.org/pipermail/community/2013-August/068850.html Look in the ffstools directory. Now I need to write some more documentation and make a release tarball for the FTP site. Stay tuned; I'll post here when I make that release. > By the way, yes, a distro able to flash and back-up everything without > additional cables would be very appreciated. Of course... Shortage of qualified volunteer manpower is our only limit. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
I did not publish it in the mailing list, so here is link to my manual: http://norayr.arnet.am/log/?p=113 If anyone who has wiki account wants to use it as reference, or even to copy the text entirely, feel free and encouraged to do that. 01/27/14 07:17 -ում, Giacomo 'giotti' Mariani-ը գրել է: > Hi David, Michael, all, thanks a lot for your work, it is very > emotional to see this "little" piece of freedom rising! > > I'm still not brave enough to risk my only (I mean in all my life > time so far) mobile phone, but I will soon ;-) > > By the way, I think that your work, with the right notes about > being experimental and so on of course, should also be in the > official wiki. > > A small question about the procedure you describe: is the t191 > cable only needed to backup the "vital parts of the calypso memory" > or also to write the new firmware? > > By the way, yes, a distro able to flash and back-up everything > without additional cables would be very appreciated. > > Internationalist greetings, Giacomo > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
Hi David, Michael, all, thanks a lot for your work, it is very emotional to see this "little" piece of freedom rising! I'm still not brave enough to risk my only (I mean in all my life time so far) mobile phone, but I will soon ;-) By the way, I think that your work, with the right notes about being experimental and so on of course, should also be in the official wiki. A small question about the procedure you describe: is the t191 cable only needed to backup the "vital parts of the calypso memory" or also to write the new firmware? By the way, yes, a distro able to flash and back-up everything without additional cables would be very appreciated. Internationalist greetings, Giacomo -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O< ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: testing the free calypso software
>Note that because the uSD card distro which David just put together >does not include loadtools internally (requires the use of the serial >cable instead, with loadtools running on your PC), nothing in that >distro became outdated as a result of this new loadtools release. Just >download the new loadtools and build them on your GNU/Linux PC. > Sure Michael - it's as you say. My write up and the distro are for the cable method only, so the new release of loadtools does not does not push it past sell by date. Thanks for the heads up though, because I'm eventually aiming to produce a sdcard distro that gives the option to use either method and that will need to have the latest loadtools installed. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
David Matthews wrote: > I've done a bit of work, which I hope will encourage other people to give it > a test. There is a full write up at http://winterveldt.co.za/leo2moko.html, > with links to a distro I've prepared for the sole purpose of flashing your > freerunner's calypso - either with leo2moko or moko11 firmware. Thanks, David! And just in time, I've got a new release of loadtools out: ftp://ifctfvax.Harhan.ORG/pub/GSM/FreeCalypso/loadtools-r2.tar.bz2 Changes from loadtools-r1 to loadtools-r2: * A flash ID check has been implemented in fc-loadtool, invoked automatically before doing any erase or program operations, or explicitly at any time with the flash info command. This check ensures that the type of flash chip in the target GSM device is the same as what loadtool thinks it is, based on the hardware parameters file. * fc-xram command line syntax changed slightly in order to support immediate passing of the serial line to rvinterf/rvtdump. * Miscellaneous minor polish. Note that because the uSD card distro which David just put together does not include loadtools internally (requires the use of the serial cable instead, with loadtools running on your PC), nothing in that distro became outdated as a result of this new loadtools release. Just download the new loadtools and build them on your GNU/Linux PC. VLR, SF ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing the free calypso software
^_~ whoops >There is a full write up at http://winterveldt.co.za/leo2moko.html,with http://winterveldt.co.za/leo2moko.html is correct -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
testing the free calypso software
As the author claims, I've found his early steps towards a freeing of the calypso modem to work in the same way as the official moko11 release. Also the tools he's provided work equally well for flashing the moko11 firmware onto the freerunner as they do his own leo2moko-r1 offering. I've done a bit of work, which I hope will encourage other people to give it a test. There is a full write up at http://winterveldt.co.za/leo2moko.html, with links to a distro I've prepared for the sole purpose of flashing your freerunner's calypso - either with leo2moko or moko11 firmware. The distro runs from sdcard and boots from the freerunners NOR menu, so you do not need to disturb anything in NAND. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
