From pedrocab at gmail.com  Wed Mar  1 11:02:04 2017
From: pedrocab at gmail.com (Pedro Cabrera)
Date: Wed, 1 Mar 2017 12:02:04 +0100
Subject: Trying to use simtrace with 4FF NFC/SIM cards
In-Reply-To: <CAA5HZHbrJZfLa_8HMjbeVF_H3fy3EhaVcPWfccHCg+ctHUdzNQ@mail.gmail.com>
References: <CAA5HZHbrJZfLa_8HMjbeVF_H3fy3EhaVcPWfccHCg+ctHUdzNQ@mail.gmail.com>
Message-ID: <CAA5HZHaF7iYVOd6XM+VU1tNZDDa-MmJA1sgu447rVCvUiv0pFQ@mail.gmail.com>

Hi all,

Just to update, I found something interesting, the Single Wire Protocol:
NFC applications on the UICC can communicate to the NFC chip using the SWP
interface. Reading on GSMA docs, I found the ETSI TS 102 613 "UICC -
Contactless Front-end (CLF) Interface". So looks like is not about 3GPP,
but ETSI standards. Also very interesting the GSMA "Requirements for Single
Wire Protocol NFC Handsets":
http://www.gsma.com/digitalcommerce/wp-content/uploads/2012/03/gsmarequirementsforswpnfchandsetsv4.pdf

I continue trying to identify why SCR3310 and simtrace aren't able to read
this SIM cards (UICC). Reading simtrace AT91SAM datasheet, it just states
"ISO7816, T0 or T1 protocols for interfacing with smart cards", while
SCR3310 v2 technical specifications are;
-T=1, T=0 protocol support
-ISO 7816 Class A, B and C SmartCard
-and CT-API (through wrapper on top of PC/SC)

I will continue analyzing the ATR for this SIM cards.

Regards,
Pedro


2017-02-27 17:03 GMT+01:00 Pedro Cabrera <pedrocab at gmail.com>:

> Hi all,
>
> I come to all of you as I'm trying to use simtrace to capture the UE-SIM
> traffic with a 4G+ SIM card, called "next gen SIM card" (the ones with
> NFC). The only thing I see is the ATR, and the mobile never detects the SIM
> card. I try also to read the SIM card plugin directly into the SCR3310 card
> reader, but the reader didn't recognize the SIM card (no led activity).
>
> At the beginning I thought this must be a new standard for the NFC/SIM
> cards, but reading 3GPP TS 31.101 V13.2.0 (2016-06), I understood only
> Class B and C operating conditions should be supported by 3G MEs (page 10
> of the document), and using transmission protocols T=0 and T=1. So looks
> like nothing has change in the protocols/electrical conditions.
>
> I look for 3GPP specs folder searching for something related with this
> NFC/SIM (http://www.3gpp.org/DynaReport/31-series.htm), but nothing
> appear. Also searching in google about this simcards I just found Orange
> document describing the business strategy to use NFC services/wallet;
>
> "On February 21st 2011 many of the world?s leading mobile operators (15 in
> total) including Orange announced their collective commitment to SIM-based
> mobile NFC and intention to launch commercial mobile NFC services. In
> November 2011, the Chinese MNOs increased the momentum of support to SIM
> based NFC. In January, GSMA communicated that more than 60 MNOs now support
> these initiatives."
>
> Source: https://www.orange.com/en/content/download/12418/258640/
> version/1/file/Orange%2BNFC%2Band%2BOrange%2BMoney%2BFact%
> 2BSheet%2B-%2BFebruary%2B2013.pdf
>
> But still didn't found any technical spec for this sim cards. Most strange
> for me is that plugging this SIM card in an old Samsung Galaxy S3 is
> working normally, so ask myself why plugging in SCR3310 reader or simtrace
> is not working.
>
> Can anyone help me with this SIM cards specifications? Does anyone been
> able to read with SIM readers?
>
> Best Regards,
> Pedro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20170301/fa4d9136/attachment.htm>

From laforge at gnumonks.org  Wed Mar  1 12:16:53 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 1 Mar 2017 13:16:53 +0100
Subject: Trying to use simtrace with 4FF NFC/SIM cards
In-Reply-To: <CAA5HZHaF7iYVOd6XM+VU1tNZDDa-MmJA1sgu447rVCvUiv0pFQ@mail.gmail.com>
References: <CAA5HZHbrJZfLa_8HMjbeVF_H3fy3EhaVcPWfccHCg+ctHUdzNQ@mail.gmail.com>
 <CAA5HZHaF7iYVOd6XM+VU1tNZDDa-MmJA1sgu447rVCvUiv0pFQ@mail.gmail.com>
Message-ID: <20170301121653.jpvayros4n3yalwb@nataraja>

I think the best way to analyze this is to understand the exact voltage,
clock rate and Fi/Di values your card is operating on on the working
reader(s).  Most likely at least one of the parameters is different on
the non-working readers.

You should be able to figure all the related values out if you talk
CCID directly to the USB device, or extend / "hack up" the ccid driver
you're using.  Alternatively, an oscilloscopse should also be able to
tell you related information.

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 pedrocab at gmail.com  Thu Mar  2 20:30:01 2017
From: pedrocab at gmail.com (Pedro Cabrera)
Date: Thu, 2 Mar 2017 21:30:01 +0100
Subject: Trying to use simtrace with 4FF NFC/SIM cards
In-Reply-To: <20170301121653.jpvayros4n3yalwb@nataraja>
References: <CAA5HZHbrJZfLa_8HMjbeVF_H3fy3EhaVcPWfccHCg+ctHUdzNQ@mail.gmail.com>
 <CAA5HZHaF7iYVOd6XM+VU1tNZDDa-MmJA1sgu447rVCvUiv0pFQ@mail.gmail.com>
 <20170301121653.jpvayros4n3yalwb@nataraja>
Message-ID: <CAA5HZHYZyWULpXrJGPc8M3xkqjtDEVg15XX8SouCwHHzxhjKFw@mail.gmail.com>

Before proceed with oscilloscope, I do a last test using simtrace and a
Samsung Galaxy S3 with this UICC and surprisingly it works, so I have the
ATR APDU:  3b 9f 96 c0 0a 3f c7 a0 80 31 e0 73 fe 21 1b 65 d0 01 74 0e a1
81 0f 9c

>From there; Fi=512, Di=32, Protocol T=0, class accepted by the card: A, B
and C (
https://smartcard-atr.appspot.com/parse?ATR=3b9f96c00a3fc7a08031e073fe211b65d001740ea1810f9c
)

After this, I test over and over again with the same UICC card and an
iPhone6 but never got ATR response, just got "ATR APDU: " and iPhone don't
recognize SIM card. SCR3310 reader never recognizes the card, always "Card
state: Card inserted, Unresponsive card" response.

I test simtrace/iPhone6 and SCR reader using same UICC type from other
operator with same results (but working with simtrace/S.Galaxy S3)

Regards,
Pedro


2017-03-01 13:16 GMT+01:00 Harald Welte <laforge at gnumonks.org>:

> I think the best way to analyze this is to understand the exact voltage,
> clock rate and Fi/Di values your card is operating on on the working
> reader(s).  Most likely at least one of the parameters is different on
> the non-working readers.
>
> You should be able to figure all the related values out if you talk
> CCID directly to the USB device, or extend / "hack up" the ccid driver
> you're using.  Alternatively, an oscilloscopse should also be able to
> tell you related information.
>
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20170302/c236e866/attachment.htm>

From xdae3v3a at gmail.com  Thu Mar 16 13:04:50 2017
From: xdae3v3a at gmail.com (E:V:A)
Date: Thu, 16 Mar 2017 15:04:50 +0200
Subject: Current status of the SIMtrace project
Message-ID: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>

Dear Osmocom,

I have been following your SIMtrace project for some time and wanted
to build and try a few things.
However, it seem that the project is abandoned since it has not been
updated on your Wiki for ages.
I know you guys are very busy with your many other and more
interesting projects and that this project is very old, but we would
still appreciate if you could at least try to keep your own GIT repo
updated with the stuff you are showing on the wiki. For example, I
cloned the SIMtrace and opened the schematics in KiCad only to find
that the schematic is several HW versions behind the currently shown
one. So my questions are:

1. Have you abandoned the project?

2. Where can I find/download the latest Firmware, KiCad (Schematics
and PCB) design files?

3. There is a related project on GitHub that are using SIMtrace.
However, the firmware there seem different. What is the current status
of the firmware? Are you involved in that development?
https://github.com/kamwar/simlabTrace

If your answer to (1) is a Yes, then perhaps it would be better to
publish your project to GitHub instead, so that other people can help
and take over the maintenance? This is actually a great idea,
reagrdless as your Redmine/cgit based git repo is very slow and hard
to navigate and the bug tracking of GH is superior in simplicity to
anything else freely available.

Kind Regards,
E:V:A


From laforge at gnumonks.org  Thu Mar 16 14:01:34 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 16 Mar 2017 15:01:34 +0100
Subject: Current status of the SIMtrace project
In-Reply-To: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
References: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
Message-ID: <20170316140134.7rgrhiswze2sdxyt@nataraja>

Hi EVA,

nice to hear from the xda-developers hero ;)

On Thu, Mar 16, 2017 at 03:04:50PM +0200, E:V:A wrote:

> I have been following your SIMtrace project for some time and wanted
> to build and try a few things.

great.

> However, it seem that the project is abandoned since it has not been
> updated on your Wiki for ages.

Well, it is a collaborative effort.  With several hundred SIMtrace
device owners out there, one would hope that the wiki gets updated by
users if they find something is out of date.

> I know you guys are very busy with your many other and more
> interesting projects and that this project is very old, but we would
> still appreciate if you could at least try to keep your own GIT repo
> updated with the stuff you are showing on the wiki. 

> For example, I cloned the SIMtrace and opened the schematics in KiCad
> only to find that the schematic is several HW versions behind the
> currently shown one.

revision 1.4 (1.4p where 'p' is just for production) of the hardware has
been current since 2014.

> 1. Have you abandoned the project?

Not really. SIMtrace v1.4 has been produced and sold in hundreds of
units and is successful from that point of view.  There are plenty of
users around the world.  We still ship several units every week from
sysmocom (and of course don't know who might have built their own
circuit boards).

What I believe it suffers from is however a very "consumerist" behavior
of many users.  Meaning that they obtain the device and use the existing
firmware + host software, without understanding (or caring about) the
fact that it is a collaborative project that only lives by
contributions.  Look at the mailing list archive and the git repository
commit history to see how limited contributions there were so far.
Basically Kevin, Holger and I did most of the initial development in
2011/2012, and then there was one patch series from Min Xu in 2014 - and
that's it!

I understand that contributing to the hardware is not easily possible
for people without EE skills.  But contribution on the firmware and on
the host software is possible for anyone with a C development
background.

So SIMtrace suffers the fate of many, many other projects that I
developed and/or was involved in developing:  It does what the original
author[s] wanted it to do, but it stays very far behind its potential as
nobody seems to be interested in making it do more than it did ever
since its creation.

Osmocom has always been open to anyone. Anyone can post patches to the
mailing list, anyone can get write permissions to the wiki. Simply
register an account and let us know.  The more popular/active projects
have moved patch submission to gerrit at https://gerrit.osmocom.org/ -
for SIMtrace there simply was not enough activity to bother.

Behind the scenes we've been working on-and-off during several year on a
hardware + software refresh called 'simtrace 2'.  The controller has
been changed from SAM7S to SAM3S, which supports more USB endpoints and
thus allows for mor versatile USB confiugrations CCID / Card-Emulation /
Tracing, unlike the SIMtrace 1.x  which is basically tracing only due to
the limited number of USB endpoints.  However, the firmware has still
not yet reached a stage where it can do anything useful beyond SIM card
emulation / forwarding, so I've refrained from announcing it anywhere
before it reaches a point where it can do SIM tracing (like v1.x) as
well as card emulation and there is some documentation on how to use it.

The current work in progress for the firmware is in
git://git.osmocom.org/simtrace2 but as stated I think it's not ready for
wider consumption.  The firmware is a complete rewrite without the
legacy of the openpcd project that lives in the SIMtrace v1.x firmware.

The initial v2.0 hardware is exactly the v1.4p simtrace board, but with
a AT91SAM3S soldered instead of the AT91SAM7S.

My roadmap would be to:
* complete SIM tracing, card emulation and CCID in simtrace2.git
* write related documentation
* start to transition to v2.x in the webshop
* maybe, if there is sufficient interest, try to port the v2.x firmware
  to v1.x, although it's rather comprehensive task due to the ARM7TDMI
  <-> Coretx-M3 transition.  At least the tracing and card-reader
  functions should work in theory, MITM will be v2.x only.  Advantage
  would be identical USB protocol to the host and identical host
  utilities for both v1.x and v2.x.

If anybody wants to help, by all means, you're more than welcome.

> 2. Where can I find/download the latest Firmware, KiCad (Schematics
> and PCB) design files?

* schematics + PCB design files for v1.4 are in the simtrace.git repo
  https://git.osmocom.org/simtrace/ git://git.osmocom.org/simtrace

* firmware source code is in http://git.osmocom.org/openpcd/
  git://git.osmocom.org/openpcd

> 3. There is a related project on GitHub that are using SIMtrace.
> However, the firmware there seem different. What is the current status
> of the firmware? Are you involved in that development?
> https://github.com/kamwar/simlabTrace

I don't recall having seen this before, so I cannot comment on it.

> If your answer to (1) is a Yes, then perhaps it would be better to
> publish your project to GitHub instead, so that other people can help
> and take over the maintenance? 

>From my point of view, I don't think there's a lack of maintenance,
there's just a lack of patches to integrate.  If people on this list
disagree, please let me know, by all means.

> This is actually a great idea, reagrdless as your Redmine/cgit based
> git repo is very slow and 

This is the first time we have received complaints about the cgit or
actual git servers being slow.  All of the Osmocom projects are hosted
there, and most of them are significantly more complex than SIMtrace.

Maybe it relates to geography.  Most developers appear to be in
continental Europe.  Where are you based? Can you send a tracerounte?

The redmine interface to git is slow, but then that's exactly why cgit
is running.  Maybe we should disable it in redmine?

> hard to navigate and the bug tracking of GH is superior in simplicity
> to anything else freely available.

yes, and once we all use proprietary "cloud" services we will all become
dependant on them.  "freely available right now" is "Free as in Beer"
but not "Free as in Freedom".  Also look at formerly large sites like
google code or gitorius, and how they disappeared and what it meant for
many projects.   Not to forget the recent backup/restore issues at
gitlab...

Finally, even in terms of "free as in beer", nothing can guarantee you
that github will stay free of cost for FOSS projects forever.  Just wait
until another investor comes around, and then they will start to SPAM
all your usrs with advertisements or the like.

I really don't like to have FOSS projects depend in their development on
non-FOSS software.  I also don't like central/single points of failure,
whether they're called SourceForge some decade[s] ago, or whether
they're called github now.

There are many FOSS projects that are not hosted on github, many of them
way before github existed.  If somebody claims they cannot or will not
contribute because it is too difficult to register an account on our
redmine, or to enroll their ssh key for commit access, then I am
somewhat doubtful as to how large their interest really is to
contribute.  Wouldn't you agree?

One of the strength of the FOSS culture is the fact that it is
distributed and diverse.  Reliance on a single service just because it
is convenient is not a good excuse to give up that diversity and
resilience.

FYI: there are some automatically mirrored repositories at
https://github.com/osmocom and I'm happy to extend those to the simtrace
related repositories, if it helps.  We have an auto-responder in case
somebody sends pull requests, indicating to them how to submit patches
to our projects instead.

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 xdae3v3a at gmail.com  Thu Mar 16 15:53:30 2017
From: xdae3v3a at gmail.com (E:V:A)
Date: Thu, 16 Mar 2017 17:53:30 +0200
Subject: Current status of the SIMtrace project
In-Reply-To: <20170316140134.7rgrhiswze2sdxyt@nataraja>
References: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
 <20170316140134.7rgrhiswze2sdxyt@nataraja>
Message-ID: <CAFQZiU_gE-SNg1uyNa3DKzifhX_Ny=kc_3pwUg5e0SyRWtJqyQ@mail.gmail.com>

Hello Harald,

Nice to hear from you so quickly and directly.

On Thu, Mar 16, 2017 at 4:01 PM, Harald Welte <laforge at gnumonks.org> wrote:

>> However, it seem that the project is abandoned since it has not been
>> updated on your Wiki for ages.
>
> Well, it is a collaborative effort.  With several hundred SIMtrace
> device owners out there, one would hope that the wiki gets updated by
> users if they find something is out of date.

Aha, I understand. Well, that is exactly the problem. Today developers are
very sensitive and lazy to signing up to anything, unless its a one-click
operation. In addition, most people visiting your site, probably have no idea
that they can actually contribute to that Wiki.  (more about this later...)


>> For example, I cloned the SIMtrace and opened the schematics in KiCad
>> only to find that the schematic is several HW versions behind the
>> currently shown one.
>
> revision 1.4 (1.4p where 'p' is just for production) of the hardware has
> been current since 2014.

Sorry, my bad. I was looking only in the master branch, hoping that
would reflect latest production releases. And they are not named "1.4p",
AFAICT, but:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/debian
  remotes/origin/master
  remotes/origin/v1.0_production
  remotes/origin/v1.1_discontinued
  remotes/origin/v1.1_production
  remotes/origin/v1.2_production
  remotes/origin/v1.3
  remotes/origin/v1.4
  remotes/origin/v1.5

So I found the 1.5 schematics and it simply look funny as there are
a number of "??" parts covering others while others are unconnected...


>> 1. Have you abandoned the project?
>
> Not really. SIMtrace v1.4 has been produced and sold in hundreds of
> ...
> Look at the mailing list archive and the git repository
> commit history to see how limited contributions there were so far.
> Basically Kevin, Holger and I did most of the initial development in
> 2011/2012, and then there was one patch series from Min Xu in 2014 - and
> that's it!
>
> I understand that contributing to the hardware is not easily possible
> for people without EE skills.  But contribution on the firmware and on
> the host software is possible for anyone with a C development
> background.
>
> So SIMtrace suffers the fate of many, many other projects that I
> developed and/or was involved in developing:  It does what the original
> author[s] wanted it to do, but it stays very far behind its potential as
> nobody seems to be interested in making it do more than it did ever
> since its creation.
>
> Osmocom has always been open to anyone. Anyone can post patches to the
> mailing list, anyone can get write permissions to the wiki. Simply
> register an account and let us know.

Again, I sincerely believe this is because the contribution threshold is
way too high for most small and highly technical projects like this. As I
mentioned above, people simply don't use mailing lists anymore and
they certainly hate to have to email their patches, just to find out that
they conflict or have some other minor errors that prevents them from
getting implemented. The turn-around-time for all this is way beyond what
most hobby/FOSS developers want to deal with. In addition, I can tell
what I learned from my own experience of failed projects. That unless
the original developer or other highly skilled (in that project) is watching
and maintaining it (from a feedback point of view) like a Hawk, it will
quickly disintegrate and people will start doing weird shit all over, if not
breaking it all together. Then for sure its dead.


> The more popular/active projects
> have moved patch submission to gerrit at https://gerrit.osmocom.org/ -
> for SIMtrace there simply was not enough activity to bother.

Cool, probably move it there. (more below..)


> Behind the scenes we've been working on-and-off during several year on a
> hardware + software refresh called 'simtrace 2'.  The controller has
> been changed from SAM7S to SAM3S, which supports more USB endpoints and
> thus allows for more versatile USB configurations CCID / Card-Emulation /

I don't see why you need more USB endpoints for this? Isn't it enough
with 1-2 since the 2 IF are using the UARTs. Shouldn't all the Tracing, MiTM
and Emulation be done in the FW?

SIM1 = UART1 <==> "M3" <==> UART2 == SIM2
                                 //
PC <---> USB <====//


> Tracing, unlike the SIMtrace 1.x  which is basically tracing only due to
> the limited number of USB endpoints.  However, the firmware has still
> not yet reached a stage where it can do anything useful beyond SIM card
> emulation / forwarding, so I've refrained from announcing it anywhere
> before it reaches a point where it can do SIM tracing (like v1.x) as
> well as card emulation and there is some documentation on how to use it.
>
> The current work in progress for the firmware is in
> git://git.osmocom.org/simtrace2 but as stated I think it's not ready for
> wider consumption.  The firmware is a complete rewrite without the
> legacy of the openpcd project that lives in the SIMtrace v1.x firmware.

Great! How well is the FW code compartmentalized in the sense that
it can be used with or easily ported to different HW?


> My roadmap would be to:
> * complete SIM tracing, card emulation and CCID in simtrace2.git
> * write related documentation
> * start to transition to v2.x in the webshop
> * maybe, if there is sufficient interest, try to port the v2.x firmware
>   to v1.x, although it's rather comprehensive task due to the ARM7TDMI
>   <-> Coretx-M3 transition.  At least the tracing and card-reader
>   functions should work in theory, MITM will be v2.x only.  Advantage
>   would be identical USB protocol to the host and identical host
>   utilities for both v1.x and v2.x.

Sound like the perfect opportunity to try GitHub! ;)


>> 3. There is a related project on GitHub that are using SIMtrace.
>> However, the firmware there seem different. What is the current status
>> of the firmware? Are you involved in that development?
>> https://github.com/kamwar/simlabTrace
>
> I don't recall having seen this before, so I cannot comment on it.

Please have a good look. It is quite nicely documented with beautiful
pictures. I'd like to know how their FW and SW compares to your
developments, and if something new have been already implemented?


> From my point of view, I don't think there's a lack of maintenance,
> there's just a lack of patches to integrate.  If people on this list
> disagree, please let me know, by all means.

Hey People, please speak up now!


>> This is actually a great idea, reagrdless as your Redmine/cgit based
>> git repo is very slow and
>
> This is the first time we have received complaints about the cgit or
> actual git servers being slow.  All of the Osmocom projects are hosted
> there, and most of them are significantly more complex than SIMtrace.

Yes, my unclarity. cgit is ok, although I never liked navigating there either.
It's your Redmine GIT/repo integration that is horrible. E.g. It doesn't show
time stamps and when you hit browser back button it puts you back in the
beginning rather than on the page you saw before the current one.


>> hard to navigate and the bug tracking of GH is superior in simplicity
>> to anything else freely available.
>
> yes, and once we all use proprietary "cloud" services we will all become
> ...
> I really don't like to have FOSS projects depend in their development on
> non-FOSS software.  I also don't like central/single points of failure,
> whether they're called SourceForge some decade[s] ago, or whether
> they're called github now.
>
> There are many FOSS projects that are not hosted on github, many of them
> way before github existed.  If somebody claims they cannot or will not
> contribute because it is too difficult to register an account on our
> redmine, or to enroll their ssh key for commit access, then I am
> somewhat doubtful as to how large their interest really is to
> contribute.  Wouldn't you agree?

I agree with most of what you say above, but this is the world we live
in and try to be productive in. The same arguments can be used against
your company, suddenly someone offers you a billion EUR and then
the party is over. If you want to be productive, we need to use the best
tools currently available and not worry so much what will happen to those
2 years down the line.

Seeing in general how things are developing with privately maintained FOSS,
I really think we should consider making some compromise. A good idea
would be to do the opposite of what you proposed, by making your GitHub
the offical repo and use instead your private as a mirror. As a FOSS you can
also have free private repos.

Kind Regards,
E:V:A


From pedrocab at gmail.com  Fri Mar 17 01:45:57 2017
From: pedrocab at gmail.com (Pedro Cabrera)
Date: Fri, 17 Mar 2017 02:45:57 +0100
Subject: Trying to use simtrace with 4FF NFC/SIM cards
In-Reply-To: <CAA5HZHYZyWULpXrJGPc8M3xkqjtDEVg15XX8SouCwHHzxhjKFw@mail.gmail.com>
References: <CAA5HZHbrJZfLa_8HMjbeVF_H3fy3EhaVcPWfccHCg+ctHUdzNQ@mail.gmail.com>
 <CAA5HZHaF7iYVOd6XM+VU1tNZDDa-MmJA1sgu447rVCvUiv0pFQ@mail.gmail.com>
 <20170301121653.jpvayros4n3yalwb@nataraja>
 <CAA5HZHYZyWULpXrJGPc8M3xkqjtDEVg15XX8SouCwHHzxhjKFw@mail.gmail.com>
Message-ID: <CAA5HZHYLjZNe6TTxef26m8fecMkEg07aSdwU=FocsX5R7pNhNw@mail.gmail.com>

Hi,

I've been testing the NFC sim with oscilloscope with this results:

- I use the new Omnikey 3121 reader, it was able to read the sim card. Vcc
= 5V, Vpp = 3V, CLK = 5 Mhz.

- I try again to read same sim card with SCR 3310, but no way to do it; no
green LED, Vcc = 0. I check with an old GRcard SIM, Vcc = 5V, Vpp = 0V, CLK
= 5Mhz.

As SCR 3310 reader is unable to read this NFC sim cards, could be because
are not implementing OpenCard Framework API (implemented only by Omnikey
reader) ?

After test with both readers, I get back to iPhone:

- Using the sim card without simtrace: Vcc = 1.8V, Vpp = 0V and 5Mhz CLK.

- simtrace w/ iPhone SE:
        * only 2 times wasn't unable to recognize the sim card ("NO SIM
card" message), that I guess could be mechanical problems due to wires,
cables and so on.
       * when was able to read the sim, Vcc is always 3V (as in specs), Vpp
= 0V and CLK 5 Mhz, but never was able to trace; or just nothing after "ATR
APDU:" or gets stuck after a few very strange lines in which bytes CLA
doesn't make sense:

APDU: 00 00 04 b0 00 ff ff
APDU: 02 90 00 *00 a4 00 04*
APDU: *02 a4 6f 07* 61 22 00
APDU: c0 00 00 22 c0 62 20

Looks like order or synchronization is lost, as you can see a regular APDU
highlighted between two lines. Could be this issue related with the T=0
implementation?: "*Unfortunately, the Rx Timeout feature of the USART is
not working in T=0 mode, so I had to re-implement Rx timeout (waiting time)
handling by means of the TC (timer/counter) block 0. Due to technical
limitations, we will wait up to one byte (12 etu) more than we should*."

Regards,
Pedro


2017-03-02 21:30 GMT+01:00 Pedro Cabrera <pedrocab at gmail.com>:

> Before proceed with oscilloscope, I do a last test using simtrace and a
> Samsung Galaxy S3 with this UICC and surprisingly it works, so I have the
> ATR APDU:  3b 9f 96 c0 0a 3f c7 a0 80 31 e0 73 fe 21 1b 65 d0 01 74 0e a1
> 81 0f 9c
>
> From there; Fi=512, Di=32, Protocol T=0, class accepted by the card: A, B
> and C (https://smartcard-atr.appspot.com/parse?ATR=
> 3b9f96c00a3fc7a08031e073fe211b65d001740ea1810f9c)
>
> After this, I test over and over again with the same UICC card and an
> iPhone6 but never got ATR response, just got "ATR APDU: " and iPhone don't
> recognize SIM card. SCR3310 reader never recognizes the card, always "Card
> state: Card inserted, Unresponsive card" response.
>
> I test simtrace/iPhone6 and SCR reader using same UICC type from other
> operator with same results (but working with simtrace/S.Galaxy S3)
>
> Regards,
> Pedro
>
>
> 2017-03-01 13:16 GMT+01:00 Harald Welte <laforge at gnumonks.org>:
>
>> I think the best way to analyze this is to understand the exact voltage,
>> clock rate and Fi/Di values your card is operating on on the working
>> reader(s).  Most likely at least one of the parameters is different on
>> the non-working readers.
>>
>> You should be able to figure all the related values out if you talk
>> CCID directly to the USB device, or extend / "hack up" the ccid driver
>> you're using.  Alternatively, an oscilloscopse should also be able to
>> tell you related information.
>>
>> 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)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20170317/b22d3bbe/attachment.htm>

From xdae3v3a at gmail.com  Fri Mar 17 11:30:43 2017
From: xdae3v3a at gmail.com (E:V:A)
Date: Fri, 17 Mar 2017 13:30:43 +0200
Subject: New hardware support or replacement proposal
Message-ID: <CAFQZiU-u69uoh4qeccJr05zeo=+534r4S9q5weXs0KVkDcAnNw@mail.gmail.com>

Dear SIMtrace Developers,

After having spent a few days reviewing your SIMtrace hardware and FW
and its development,
I would like to propose you to consider supporting the following project.

Background:

The current SIMtrace processor (AT91SAM7) is based on the 55 MHz
ARMv4T uP, whereas the next generation SIMtrace2 is to use (AT91SAM3)
which is based on a 96 MHz Cortex-M3. This is all great and dandy, but
it does limit the hardware and software development to people who are
already very familiar with that hardware. Why are these needed? They
are needed so that we can have 2 SIM (USART) interfaces and that we
can translate the signals found on those to/from a USB endpoint on the
USB port. This is all done in the firmware, written in C + Assembly.

Proposal:

The new project would utilize a RaspberryPi-Zero-W in the external
slave configuration or a RPi3 doubling as a host. The RPi-0 is a 1GHz
ARM processor (ARM1176JZF-S) and could possibly also be used as a
headless host via WiFi. (RPi0 has OTG USB, RPi3 doesn't.) The Rpi3 is
a quad-core 64-bit Cortex-A53, that can be used as anything. Thus
porting A53 to M3 might be more easy.

Advantages:

There are too many advantages to ignore...
- The huge RPi developer community
- The high clockspeed and 512+ Mb of RAM
- All interfaces you can dream of, except JTAG
- A huge reduction on the BOM. I've counted that we may remove about
50 components by using this solution instead of the current v1.3 one.
- A huge reduction to about 1/3 of what is currently used of the PCB footprint.
- A large reduction of production price due to above.
- Easy to port drivers when understood
- Provide a more attractive and useful product combo (RPi-0 + ST hat)
than what is currently offered.

Disadvantages:

- Need porting of current FW drivers to RPi's
- Possible proprietary limitation to the complete Broadcom datasheets
- Need to CAD and manufacture a new PCB
- New Rpi-0/3 drivers would need testing for use with 2 SIM IF's.

Other:

The RPi's only has one UART so to get a second, we need to use
bit-banging of their GPIO,SPI or I2C. There are already solutions out
there and the much higher clock-rate of both devices allow you to run
up to 250 MHz on a single GPIO pin, so that would allow you to
multiplex a number of virtual/emulated UARTs. (Perhaps similarly to
what was already done when SIMtrace was using the FT232r?) The library
used for this is the PGPIO from here:
http://abyz.co.uk/rpi/pigpio/download.html
and a Python based test-script can be found here:
https://www.rs-online.com/designspark/raspberry-pi-2nd-uart-a-k-a-bit-banging-a-k-a-software-serial

Finally, please don't get me wrong. This is not at all a critique of
what has already been done. The development of the ST is a great piece
of work and obviously very flexible and cross platform compatible by
using USB, but for compact embedded devices, such as RPi's etc, all
that extra HW is redundant and expensive to produce and maintain. Even
more so than combining the RPi + this add-on, while improving cross
platform connectivity and IoT support.

I would love to hear what the community and Osmocom think about this.

Cheers,
E:V:A


From laforge at gnumonks.org  Fri Mar 17 15:09:22 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Mar 2017 16:09:22 +0100
Subject: New hardware support or replacement proposal
In-Reply-To: <CAFQZiU-u69uoh4qeccJr05zeo=+534r4S9q5weXs0KVkDcAnNw@mail.gmail.com>
References: <CAFQZiU-u69uoh4qeccJr05zeo=+534r4S9q5weXs0KVkDcAnNw@mail.gmail.com>
Message-ID: <20170317150922.hw7biokgt4helslb@nataraja>

Hi E:V:A,

On Fri, Mar 17, 2017 at 01:30:43PM +0200, E:V:A wrote:

> The current SIMtrace processor (AT91SAM7) is based on the 55 MHz
> ARMv4T uP, whereas the next generation SIMtrace2 is to use (AT91SAM3)
> which is based on a 96 MHz Cortex-M3. This is all great and dandy, but
> it does limit the hardware and software development to people who are
> already very familiar with that hardware. Why are these needed? They
> are needed so that we can have 2 SIM (USART) interfaces and that we
> can translate the signals found on those to/from a USB endpoint on the
> USB port. This is all done in the firmware, written in C + Assembly.

The AT91SAMxx controllers have been specifically chosen as they are the
only controllers I could find on the market which allow (even though not
officially explicitly documented) an UART in ISO7816-mode on the *card
side*.

A normal UART does not typically support ISO7816 mode.  Yes, you can
hack together something like a "Phoenix style" reader with wiring
together Rx and Tx of a regular (RS-232 style) UART, but you will
violate smard card interface specs in all places back and forward.

While a lot of microcontrollers have ISO7816 support in the UART, the
hardware is designed in a way that restricts this to implementing the
Reader-Side of ISO7816, and not the Card side - be alone a passive
tracing.

The requirements are subtly different between those modes, for example
when it comes to
* who is a master and who is a slave of the clock
* being able to count the clock cycles to derive ETU and Waiting Time
  from it
* the card generates the ACK/NACK in case of partiy error, while the
  reader or a sniffer doesn't

So I am somewhat puzzled how you would want to do this (and do it
"correctly" as per the ISO7816-1/-2/-3) with generic UARTs that have no
ISO7816 moe to begin with?

> There are too many advantages to ignore...
> - The huge RPi developer community

Who - no offence - most likely don't understand the intrinsics of
ISO7186?  I don't want to be cynical, but if people wanted to contribute
to the SIMtrace project, they could have done so in pure software, by
simply extending/completing the wireshark dissectors beyond my initial
code.  Until today, the contents of the EFs are not decoded, for
example.  Would be great if the were, but they weren't.  I don't think
this will change based on whether we use a Raspberry Pi or not on the
hardware side.

> - The high clockspeed and 512+ Mb of RAM

Not sure that is an advantage?  Why is that an advantage?  We don't use
most of the orders-of-magnitude lower RAM nor flash on the existing
devices even in the past years.

> - All interfaces you can dream of, except JTAG

...and JTAG is probably the most useful interface you can have when
implementing low-level code that's very close to hardware?

> - A huge reduction on the BOM. I've counted that we may remove about
> 50 components by using this solution instead of the current v1.3 one.

There's no problem with the BOM part count as-is?  Also.

> - A huge reduction to about 1/3 of what is currently used of the PCB footprint.

well, but then you have a RPi alongside with that, which is larger than
the original PCB footprint

> - A large reduction of production price due to above.

not sure if the production cost difference really matters.

> - Easy to port drivers when understood

Depends on what exact hardware interface you will come up to handle the
ISO7816 lower layers.  The complexity is mostly in the ISO7816 state
machines, and they won't change.

And to be honest, I don't think an in-kernel-bitbanging
implementation/driver of a ISO7816 soft-uart is going to be easy to
understand (it just has to replicate what the SAMx hardware has), and it
will particularly not be easy to develop and/or debug.

With the SAMx based devices, I have probably about 15-20 seconds of
development cycles between making a change, reflashing + restarting the
board via DFU, and running the new software.  Try that with re-compiling
kernel code, crashing your entire board and having to reboot Linux all
the time, ...

> The RPi's only has one UART so to get a second, we need to use
> bit-banging of their GPIO,SPI or I2C. There are already solutions out
> there and the much higher clock-rate of both devices allow you to run
> up to 250 MHz on a single GPIO pin, so that would allow you to
> multiplex a number of virtual/emulated UARTs. (Perhaps similarly to
> what was already done when SIMtrace was using the FT232r?) 

Ok, so you'd be usign hihg-speed bit-banging and implement everyting in
software, like a 'software defined ISO7816 UART'.   That's quite some
coe that needs to be developed.

> using USB, but for compact embedded devices, such as RPi's etc, all
> that extra HW is redundant and expensive to produce and maintain. Even
> more so than combining the RPi + this add-on, while improving cross
> platform connectivity and IoT support.

I'm very happy to receive your suggestions, but what I keep wondering is
"what is the problem that he's trying to solve"?

You can probably hardly beat the performance (and power consumption) of
a small embedded device around a microcontroller.  I also would be very
surprised if you can beat the BOM cost of the existing hardware while
maintaining the same capabilities in terms of tracing, MITM, card reader
and card emulation/forwarding

The BOM cost of the SIMtrace is basically
* the SAM7/SAM3 microcontroller
* the SIM card slot
* the flexible PCB cables/adapters
* the other connectors and TVS/ESD protection
* the bus switch to connect/disconnect SIM and Phone

All of the above - except the microcontroller - you would also need in
your proposed solution *together* with a raspberry pi.  How sould all of
that have lower BOM cost?

Also, keep in mind that the SAM7/SAM3 support full industrial
temperature range, which is not offered by consumer-grade devics like
the Raspberry Pi.

I would also argue that most poeple use the SIMtrace as a
mesurement/debuggin device.  At their desk, between a phone and a SIM
card.  To do some testing/analtysis.  And doing that via a USB
peripheral is more convenient than having an ethernet or wifi attached
system, which requires an operating system (and related updates),
network configuration, etc.

I mean, we don't have Ethernet/WiFi attached chip card readers, but
USB-CCID attached ones.  We have the same for keyboard, mice, or all
kinds of other peripherals.

For specific use cases (like embedded devices with "remote SIM" feature)
we have built some devices at sysmocom that use the SAM3 + SIMtrace
firmware as part of larger embedded systems.  In that case, one or
multiple SAM3 are attached to up to four cellular modems and to some
extent also to industrial-grade ARM SoM (like TI AM335x based ones).
At that point you also have a fully-fledged embedded device with a
larger CPU, Ethernet/WiFi/etc.  - but still we decided to use the
dedicated, USB-Attached SAM3s.  Why? Because the have a reliable, known
hardware implementation of multiple fully ISO7816 compatible UARTs, and
the associated timing and state machines will run in hardware, no matter
what the linux-running main CPU of the system does.  I always prefer
hard-wired logic and bare-iron implementations on dedicated CPU cores
over any virtualized "software defined" implementation, which might or
might not at some point get pre-empted at the wrong point.

> I would love to hear what the community and Osmocom think about this.

I'm also very much looking forward to feedback from other people.

I really do appreciate your interest, but I am absolutely not convinced
that this proposal is solving any actual problem or disadvangage.

Rather than rebuilding what we alreay have based on different
technology, I would much rather like to see people invest their time in
extending what we already have.  This could be on the firmware side, but
could also be on the hardware side.  The existing PCB design is far from
great (it was one of the first circuit boards ever made by Kevin, so of
course it would look quite different by somebody who has more experience
at it). But hey, it has worked for many years :)

A new circuit board could also have support for different voltages (we
currently do only 3.3V, but with level shifters it would be possible to
do 1.8V and  5V logic levels, too).  We could design the board to fit in
some standard enclosure to avoid the "bare pcb getting short-circuited
on my desk or damaged by ESD" issue.  We could add a battery charger IC
(for charging via USB) and a small Li-Ion battery for offline tracing to
the SPI flash that we have in the design for this reason ever sinc day1,
but which nobody ever used.

For heaven's sake, in all those 5 years of SIMtrace being available,
people haven't even managed to do something as simple as to use libusb
hot-plugging API to keep the program running across SIMrtace
disconnects.  Those are really low-hanging fruits, and don't rquire any
special skills or background beyond regular C application development on
Linux.  No knowledge about hardware or SIM card protocols needed.

So I think there are *many* things that people with an interest in the
project could do.  Building a completely different hardware +
drivers/firmware to re-create what already works does not seem like the
most efficient investment in time.

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 laforge at gnumonks.org  Fri Mar 17 15:39:34 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Mar 2017 16:39:34 +0100
Subject: Current status of the SIMtrace project
In-Reply-To: <CAFQZiU_gE-SNg1uyNa3DKzifhX_Ny=kc_3pwUg5e0SyRWtJqyQ@mail.gmail.com>
References: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
 <20170316140134.7rgrhiswze2sdxyt@nataraja>
 <CAFQZiU_gE-SNg1uyNa3DKzifhX_Ny=kc_3pwUg5e0SyRWtJqyQ@mail.gmail.com>
Message-ID: <20170317153934.5t22vj723galylkj@nataraja>

hi E:V:A,

On Thu, Mar 16, 2017 at 05:53:30PM +0200, E:V:A wrote:
> Nice to hear from you so quickly and directly.

likewise.  I guess we've been working on different ends of cellular
communications during the last decade but never really crossed roads.

> > Well, it is a collaborative effort.  With several hundred SIMtrace
> > device owners out there, one would hope that the wiki gets updated by
> > users if they find something is out of date.
> 
> Aha, I understand. Well, that is exactly the problem. Today developers are
> very sensitive and lazy to signing up to anything, unless its a one-click
> operation.

I find that hard to believe. Today, contrary to 20 or even 10 years ago,
almost every website requires you to register, so I somehow doubt that.
We even support OpenID based authentication on our redmine, so you
should be able to log in with many other accounts.  That won't give you
write permission (see below), but maybe we can do something about that.

Also, if you cannot even bother to send a patch series by e-mail, or
send an e-mail to request commit / write access, then I don't think you
have time or energy to contribute to a project.  After all, what is the
one minute to send that mail compared to the many hours, days or weeks
of your life you're working on the actual contribution?

> In addition, most people visiting your site, probably have no idea
> that they can actually contribute to that Wiki.  (more about this later...)

We can either
* update the wiki to explicitly explain that, even add it to every page
* re-enable public registration with write permissions with some
  automatic spam filtering (wiki spam was the reason to disable it some
  years ago)

> > revision 1.4 (1.4p where 'p' is just for production) of the hardware has
> > been current since 2014.
> 
> Sorry, my bad. I was looking only in the master branch, hoping that
> would reflect latest production releases. And they are not named "1.4p",
> AFAICT, but:

The 'p' is for 'production', kevin introduced that some time ago, I
don't recall the exact rationale.

> So I found the 1.5 schematics and it simply look funny as there are
> a number of "??" parts covering others while others are unconnected...

1.5 was an abandoned work-in-progress and is not what has shipped to
anyone, AFAICT.

v1.4p is what all circuit boards of recent years are labelled, so the
v1.4 tag is applicable.  The schematics should render nicely.

I've updated the wiki with a png and pdf schematics as well as gerber
for that revision. 

> > Osmocom has always been open to anyone. Anyone can post patches to the
> > mailing list, anyone can get write permissions to the wiki. Simply
> > register an account and let us know.
> 
> Again, I sincerely believe this is because the contribution threshold is
> way too high for most small and highly technical projects like this. As I
> mentioned above, people simply don't use mailing lists anymore and

Well, I can equally state I won't use anything else for communication.
E-mail is perfect due to its offline/asynchronous nature.  I don't have
to be connected to read/write them.  I don't need a sluggish web
browser.  I don't need a mouse, even.

> they certainly hate to have to email their patches, just to find out that
> they conflict or have some other minor errors that prevents them from
> getting implemented. 

Well, then everyone would have to hate developing on the Linux kernel?
My experience in that field is quite different, even though I haven't
been doing much kernel work in many years ;)

> The turn-around-time for all this is way beyond what most hobby/FOSS
> developers want to deal with. 

Actually, if I am not working on something full time (e.g. just in the
evenings), then the turn-around time to wait for some feedback until the
one of the next evenings I spend on the project is actually fitting very
well the rhythm of my work.   Only poeple who work on something
full-time, with a tight deadline need quick turn-around times.

> what I learned from my own experience of failed projects. That unless
> the original developer or other highly skilled (in that project) is watching
> and maintaining it (from a feedback point of view) like a Hawk, it will
> quickly disintegrate and people will start doing weird shit all over, if not
> breaking it all together. Then for sure its dead.

sure, that can very well be the case.  But then, it's always up to
people to decide what they do or what they don't do.  If somebody cares
sufficiently, then it will be revived.  If not, then it might be dead
for good.  Which is maybe sad from an emotional point of view, but why
does it matter?  If nobody is interested in (and capable of) moving a
project forward, then what's the point o the project.  People with an
actual need / itch to scratch will work on it.  And if there are no such
people, then nobody needs the project :)

> > The more popular/active projects
> > have moved patch submission to gerrit at https://gerrit.osmocom.org/ -
> > for SIMtrace there simply was not enough activity to bother.
> 
> Cool, probably move it there. (more below..)

I would argue to do that with the new simtrace2.git firmware.  With the
old code it probably makes no sense unless somebody actually has
something to submit.

> > Behind the scenes we've been working on-and-off during several year on a
> > hardware + software refresh called 'simtrace 2'.  The controller has
> > been changed from SAM7S to SAM3S, which supports more USB endpoints and
> > thus allows for more versatile USB configurations CCID / Card-Emulation /
> 
> I don't see why you need more USB endpoints for this? Isn't it enough
> with 1-2 since the 2 IF are using the UARTs. Shouldn't all the Tracing, MiTM
> and Emulation be done in the FW?

You can, but not if you want to have the "Card reader" part use a
generic driver and middleware architecture, i.e. a USB-CCID compatible
device on which you can run OpenCT or pcsc-lite and the likes.  I
strongly believe in interoperable standards.  And unfortuantely the SAM7
has insufficient USB endpoints to offer a two-interface configuratio
with one USB-CCID compatible one simultaneous to another one for the
'card emulation' part.

> > The current work in progress for the firmware is in
> > git://git.osmocom.org/simtrace2 but as stated I think it's not ready for
> > wider consumption.  The firmware is a complete rewrite without the
> > legacy of the openpcd project that lives in the SIMtrace v1.x firmware.
> 
> Great! How well is the FW code compartmentalized in the sense that
> it can be used with or easily ported to different HW?

All the peripherals of SAM7 and SAM3 are [almost] identical.  They
basically switched the CPU core and left most other parts identical.  It
shouldn't be *that* hard with the excaption of the smaller number of USB
endpoints, as indicated above.

> > My roadmap would be to:
> > * complete SIM tracing, card emulation and CCID in simtrace2.git
> > * write related documentation
> > * start to transition to v2.x in the webshop
> > * maybe, if there is sufficient interest, try to port the v2.x firmware
> >   to v1.x, although it's rather comprehensive task due to the ARM7TDMI
> >   <-> Coretx-M3 transition.  At least the tracing and card-reader
> >   functions should work in theory, MITM will be v2.x only.  Advantage
> >   would be identical USB protocol to the host and identical host
> >   utilities for both v1.x and v2.x.
> 
> Sound like the perfect opportunity to try GitHub! ;)

I'm not sure why? So far, nobody has even stated in any way that they'd
want to do some work on it [not even you *g*].

Also, as indicated before, I don't like to depend with my development on
third party web services.

> > I don't recall having seen this before, so I cannot comment on it.
> 
> Please have a good look. It is quite nicely documented with beautiful
> pictures. I'd like to know how their FW and SW compares to your
> developments, and if something new have been already implemented?

No offence, but if you have an interest in such a comparison, I suggest
you create it?

> Hey People, please speak up now!

Indeed.  I guess nobody is used to receiving mails on this list anymore ;)

> Yes, my unclarity. cgit is ok, although I never liked navigating there either.

good (first part)

> It's your Redmine GIT/repo integration that is horrible. E.g. It doesn't show
> time stamps and when you hit browser back button it puts you back in the
> beginning rather than on the page you saw before the current one.

it isn't "our" redmine git integration, but it is the git integration of
redmine.  If you don't like it, I suggest you provide feedback and/or
patches to the redmine project.

All we can do is disable it (and redirect to cgit), if more people thing
it hurts more than it helps.

> > There are many FOSS projects that are not hosted on github, many of them
> > way before github existed.  If somebody claims they cannot or will not
> > contribute because it is too difficult to register an account on our
> > redmine, or to enroll their ssh key for commit access, then I am
> > somewhat doubtful as to how large their interest really is to
> > contribute.  Wouldn't you agree?
> 
> I agree with most of what you say above, but this is the world we live
> in and try to be productive in. The same arguments can be used against
> your company, suddenly someone offers you a billion EUR and then
> the party is over. 

Which party is over?  When we started sysmocom, we made very sure that
it does not control the Osmocom projects in any way.  It doesn't hold
the trade marks, and all time Holger or I spent on development of
Osmocom code is our personal copyright, and not that of a company.
Also, there are no copyright assignments with contributors, making it a
safe guard against anyone who might want to come later to try to change
the license or whatever else.

We have started sysmocom to be able to generate business that funds more
developers and developments for Osmocom.

SIMtrace was btw. developed mostly outside sysmocom.  WE just used the
opportunity of having a company that has processes and workflows for
electronics development to provid ready-built units to interested people
who don't want to go through the effort of building it themselves.

> If you want to be productive, we need to use the best tools currently
> available and not worry so much what will happen to those 2 years down
> the line.

You are free to do what you want.  I will not compromise on this.  I am
not using non-free software to develop FOSS.  In fact, we even go beyond
this to a large extent even in sysmocom:  We do everything down to
accounting in FOSS, even non-tech staff works on Linux and the only
Windows machines are our Oscilloscope/Spectrum Analyzer/VNA.

Under some circumstances, I might even consider investing in a
source-code license of a proprietary project management software that I
could host myself, and fix/improve myself.  But I will certainly not
depend on third-party *services*, where I have no clear idea how to ever
migrate away from it, once they change their terms of service or go out
of business.

> Seeing in general how things are developing with privately maintained FOSS,
> I really think we should consider making some compromise. A good idea
> would be to do the opposite of what you proposed, by making your GitHub
> the offical repo and use instead your private as a mirror. As a FOSS you can
> also have free private repos.

I don't care where the primary git repository is hosted.  But  I do care
about not using all the non-free issue tracking and merge request
features of a proprietary service.

This discussion has been taking a significant amount of time over the
past days, and I think we have made both of our views sufficiently
clear.

I would love to see contribution from anyone, including you, in
whichever way.  I'm happy to gerrit-enable the related repositoires,
and also happy to provide SAM3-versions of the SIMtrace v1.4p boards for
free.  But I certainly won't make my development depend on tools I
cannot control.

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 laforge at gnumonks.org  Fri Mar 17 20:17:19 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Mar 2017 21:17:19 +0100
Subject: git.osmocom.org cgit improvements
Message-ID: <20170317201719.r3d6n3ab35wke4mu@nataraja>

Hi all,

today I've deployed some cgit improvements on https://git.osmocom.org/,
in the hope that it makes this tool even more useful:

1) syntax highlighting of source code (requested by Hoernchen)

The source code is now highlighted by pygments.  I don't really
understand why somebody would want to look at source code a lot in a
browser, but well, it was as easy as to enable the existing pygments
based filter plugin.


2) rendering of "about" page from README.md

As you might have noticed, I've introduced a README.md in a number of
repositoires, and cgit is now rendering an about page for every
repository, e.g. at http://git.osmocom.org/libosmo-abis/about/


3) gerrit change-ID hyperlink generation

All gerrit Change-IDs in commit messages are now automatically converted
to hyperlinks to the respective gerrit change, see e.g. the below
example:
http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c446aa563c

Please note that this works for the "Change-Id" line of the actual
change, but also for change-ids in the free text (e.g. "this depends on
change-id ... in libosmocore")


4) Osmocom ticket/issue hyperlink generation

Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
scanned for occurrences of "OS#(\d+)" which are then amended with
hyperlinks to the respective issue on osmocom.org

Please note the OS# prefix is mandatory, so things like "OS#1614, 1615"
will not work, as can be seen at
http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5b8cc85cd

Please format your commit messages accordingly.

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 ml at mail.tsaitgaist.info  Fri Mar 17 23:35:03 2017
From: ml at mail.tsaitgaist.info (=?iso-8859-1?Q?K=E9vin?= Redon)
Date: Sat, 18 Mar 2017 00:35:03 +0100
Subject: New hardware support or replacement proposal
In-Reply-To: <20170317150922.hw7biokgt4helslb@nataraja>
References: <CAFQZiU-u69uoh4qeccJr05zeo=+534r4S9q5weXs0KVkDcAnNw@mail.gmail.com>
 <20170317150922.hw7biokgt4helslb@nataraja>
Message-ID: <20170317233503.GC6097@coil>

On Fri, Mar 17, 2017 at 04:09:22PM +0100, Harald Welte wrote:
> > I would love to hear what the community and Osmocom think about this.
>
> I'm also very much looking forward to feedback from other people.
>

I share Harald's view.
The RPi would simply replace the micro-controller and this comes with a lot of disadvantages.
With the RPi you would always have to keep in sync with all the underlying layer (a complete OS), and also keep the OS up to date. Plus it's hard to guess how long this hardware would be supported and available.

The only advantage (e.g. problem it would solve) would be to make the entry level lower (writing software on an OS might be easier than low level micro-controller code). But on the other side that would also open gate for much more newcomer questions for less technically involved developer.
I don't mind newcomers, after all SIMtrace was also my first hardware project, but there are numerous other non-hardware related aspects already which didn't get any contribution (host software, wireshark dissector, or simply wiki documentation). I am not sure lowering the entry to the more technical aspects would change this.



From ml at mail.tsaitgaist.info  Fri Mar 17 23:36:27 2017
From: ml at mail.tsaitgaist.info (=?iso-8859-1?Q?K=E9vin?= Redon)
Date: Sat, 18 Mar 2017 00:36:27 +0100
Subject: Current status of the SIMtrace project
In-Reply-To: <20170317153934.5t22vj723galylkj@nataraja>
References: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
 <20170316140134.7rgrhiswze2sdxyt@nataraja>
 <CAFQZiU_gE-SNg1uyNa3DKzifhX_Ny=kc_3pwUg5e0SyRWtJqyQ@mail.gmail.com>
 <20170317153934.5t22vj723galylkj@nataraja>
Message-ID: <20170317233627.GD6097@coil>

On Fri, Mar 17, 2017 at 04:39:34PM +0100, Harald Welte wrote:

> > Sorry, my bad. I was looking only in the master branch, hoping that
> > would reflect latest production releases. And they are not named "1.4p",
> > AFAICT, but:
>
> The 'p' is for 'production', kevin introduced that some time ago, I
> don't recall the exact rationale.

we changed the v1.0 design so to fit the production. The manufacturer of the board had a surplus of some components (mosfet, diode), so we decided to replace some of the components we initially chose to speed up and ease the production (the component requirements were identical, only the footprint were different).
I think we did the same for v1.1 and v1.2, and we just kept the 'p' (for production) from there on but the design didn't need to be changed.
This confusion is now only due to historical reasons.


From nhofmeyr at sysmocom.de  Sat Mar 18 15:09:31 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 18 Mar 2017 16:09:31 +0100
Subject: git.osmocom.org cgit improvements
In-Reply-To: <20170317201719.r3d6n3ab35wke4mu@nataraja>
References: <20170317201719.r3d6n3ab35wke4mu@nataraja>
Message-ID: <20170318150931.GB3272@my.box>

On Fri, Mar 17, 2017 at 09:17:19PM +0100, Harald Welte wrote:
> 2) rendering of "about" page from README.md
> 
> As you might have noticed, I've introduced a README.md in a number of
> repositoires, and cgit is now rendering an about page for every
> repository, e.g. at http://git.osmocom.org/libosmo-abis/about/

It seems like these need some follow-ups in the debian packaging instructions
-- i.e. update to the new .md suffix or mark as installation (or ignore, but I
guess rather installation) file.

> 4) Osmocom ticket/issue hyperlink generation
> 
> Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
> scanned for occurrences of "OS#(\d+)" which are then amended with
> hyperlinks to the respective issue on osmocom.org

Ah, so when OS#123 appears in the commit log's free text, it isn't linked?
Can we just scan everything for "\<OS#\d+\>"?

All in all these are excellent improvements!
Holger, what's the status of your promise, made one day in a chat, to make
redmine catch the OS#123s?

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20170318/c20a9250/attachment.bin>

From holger at freyther.de  Sun Mar 19 20:57:57 2017
From: holger at freyther.de (Holger Freyther)
Date: Sun, 19 Mar 2017 21:57:57 +0100
Subject: git.osmocom.org cgit improvements
In-Reply-To: <20170318150931.GB3272@my.box>
References: <20170317201719.r3d6n3ab35wke4mu@nataraja>
 <20170318150931.GB3272@my.box>
Message-ID: <9437479C-B7C9-4603-B01D-EC775130F164@freyther.de>


> On 18 Mar 2017, at 16:09, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> 

Hi,


> All in all these are excellent improvements!
> Holger, what's the status of your promise, made one day in a chat, to make
> redmine catch the OS#123s?

lol, I love how we go from a private chat to this CC list. I have not looked at it but maybe this is something for an afternoon at Osmodevcon. It should be fairly simple with redmine.

holger

From nhofmeyr at sysmocom.de  Mon Mar 20 04:36:31 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Mar 2017 05:36:31 +0100
Subject: git.osmocom.org cgit improvements
In-Reply-To: <9437479C-B7C9-4603-B01D-EC775130F164@freyther.de>
References: <20170317201719.r3d6n3ab35wke4mu@nataraja>
 <20170318150931.GB3272@my.box>
 <9437479C-B7C9-4603-B01D-EC775130F164@freyther.de>
Message-ID: <20170320043631.GC12441@my.box>

On Sun, Mar 19, 2017 at 09:57:57PM +0100, Holger Freyther wrote:
> > Holger, what's the status of your promise, made one day in a chat, to make
> > redmine catch the OS#123s?
> 
> lol, I love how we go from a private chat to this CC list.

Hey, if you love it that much, I can come up with plenty more private
conversations between us I could Cc around... ;)

In other words, sorry about disclosing. I kind of remembered it was a public
commitment. And it doesn't need to stick, either, anyone could take a look if
you're busy.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20170320/99ba8078/attachment.bin>

From xdae3v3a at gmail.com  Tue Mar 21 13:48:41 2017
From: xdae3v3a at gmail.com (E:V:A)
Date: Tue, 21 Mar 2017 15:48:41 +0200
Subject: Current status of the SIMtrace project
In-Reply-To: <20170317153934.5t22vj723galylkj@nataraja>
References: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
 <20170316140134.7rgrhiswze2sdxyt@nataraja>
 <CAFQZiU_gE-SNg1uyNa3DKzifhX_Ny=kc_3pwUg5e0SyRWtJqyQ@mail.gmail.com>
 <20170317153934.5t22vj723galylkj@nataraja>
Message-ID: <CAFQZiU-6JfeeUZMtgdGL-CTDj9J13xH4zhE-eBzeqE2eph8hCQ@mail.gmail.com>

Hi Harald,

Thank you so much for taking the time to respond to all my inquiries
and challenging comments/requests. Your response has indeed convinced
me that this project is very much alive, but that it need a whole lot
more of community TLC.


On Fri, Mar 17, 2017 at 5:39 PM, Harald Welte <laforge at gnumonks.org> wrote:
> hi E:V:A,
> ...
>> Aha, I understand. Well, that is exactly the problem. Today developers are
>> very sensitive and lazy to signing up to anything, unless its a one-click
>> operation.
>
> I find that hard to believe. Today, contrary to 20 or even 10 years ago,
> almost every website requires you to register, so I somehow doubt that.
> We even support OpenID based authentication on our redmine, so you
> should be able to log in with many other accounts.  That won't give you
> write permission (see below), but maybe we can do something about that.
>
> Also, if you cannot even bother to send a patch series by e-mail, or
> send an e-mail to request commit / write access, then I don't think you
> have time or energy to contribute to a project.  After all, what is the
> one minute to send that mail compared to the many hours, days or weeks
> of your life you're working on the actual contribution?

You're probably right, but another aspect of contribution is what
effect even the smallest ones has. What I mean is, that when a
drive-by developer finds a minor error somewhere, he/she just doesn't
bother to open email and register and so on, just to send a patch for
some misspellings, minor buffer allocation error and the like, in the
hope someone else will fix it. So given the low external developer
participation in this project, it may seem dead from the outside
perspective as there are barely any new pushes or changes. Now,
perhaps I could be very wrong here, but my own thinking goes like
that. I regularly find github projects that have been forked in
dozens, and although the original or older forks are better, I still
usually choose to use one of the later ones, just to be sure that if I
do make some changes or have some comments or bugs to report, that
someone is on the receiving end..


> We can either
> * update the wiki to explicitly explain that, even add it to every page
> * re-enable public registration with write permissions with some
>   automatic spam filtering (wiki spam was the reason to disable it some
>   years ago)

Good idea.


> v1.4p is what all circuit boards of recent years are labelled, so the
> v1.4 tag is applicable.  The schematics should render nicely.
>
> I've updated the wiki with a png and pdf schematics as well as gerber
> for that revision.

Yeah, I noticed almost immediately. Very good.
Also have you tried to run the files in the latest KiCAD 4.0.6?
There are some new changes there, that require some files to be
updated. (automatic)


>> they certainly hate to have to email their patches, just to find out that
>> they conflict or have some other minor errors that prevents them from
>> getting implemented.
>
> Well, then everyone would have to hate developing on the Linux kernel?
> My experience in that field is quite different, even though I haven't
> been doing much kernel work in many years ;)

I knew you would mention this. ;)
But that has quite a different project scope doesn't it...

>
>> The turn-around-time for all this is way beyond what most hobby/FOSS
>> developers want to deal with.
>
> Actually, if I am not working on something full time (e.g. just in the
> evenings), then the turn-around time to wait for some feedback until the
> one of the next evenings I spend on the project is actually fitting very
> well the rhythm of my work.   Only poeple who work on something
> full-time, with a tight deadline need quick turn-around times.

I agree, you have me convinced.

>> > Behind the scenes we've been working on-and-off during several year on a
>> > hardware + software refresh called 'simtrace 2'.  The controller has
>> > been changed from SAM7S to SAM3S, which supports more USB endpoints and
>> > thus allows for more versatile USB configurations CCID / Card-Emulation /

I see. I would suggest trying a new approach of working on this "on
top of the scene" so that
people see that something is happening and that they can jump right in
to contribute if they want.


>> > My roadmap would be to:
>> > * complete SIM tracing, card emulation and CCID in simtrace2.git
>> > * write related documentation
>> > * start to transition to v2.x in the webshop
>> > * maybe, if there is sufficient interest, try to port the v2.x firmware
>> >   to v1.x, although it's rather comprehensive task due to the ARM7TDMI
>> >   <-> Coretx-M3 transition.  At least the tracing and card-reader
>> >   functions should work in theory, MITM will be v2.x only.  Advantage
>> >   would be identical USB protocol to the host and identical host
>> >   utilities for both v1.x and v2.x.
>>
>> Sound like the perfect opportunity to try GitHub! ;)
>
> I'm not sure why? So far, nobody has even stated in any way that they'd
> want to do some work on it [not even you *g*].

True and fair enough. I would be happy to deal with the documentation in
case I ever get my hands on the new HW.


>> Please have a good look. It is quite nicely documented with beautiful
>> pictures. I'd like to know how their FW and SW compares to your
>> developments, and if something new have been already implemented?
>
> No offence, but if you have an interest in such a comparison, I suggest
> you create it?

No offense taken. They (bodziow and kamwar) just recently responded to
my question here:
https://github.com/kamwar/simLAB/issues/1
and indeed thay have made several improvements.

--------------------------------------------------------

"We have refactored that source code (i.a. removed unneeded modules),
separated reader and forwarder functionality and added some
improvements and bugfixes. The most important work has been done on
the Python (Host) side."

and:

"simLabTrace is APDU forwarder - it receives APDU data from UE,
forward it to simLAB and send back the data from simLAB to UE. As
Szymon already mentioned, we removed unused files and do basic
refactor to split functionality between forwarder code and CCID
reader. Most changes in the firmware code are for CCID reader but
there are also several fixes and improvements for APDU forwarder.
Although original simTrace firmware should work in passive mode it
turned out that sometimes the SIM inserted into the SIM slot is not
recognized at all, e.g. simTrace doesn't allow to sniff card reader
connection (CCID reader -> simTrace -> SIM in simTrace slot). I can't
recall the exact solution for this problem but it was related with PTS
procedure."

--------------------------------------------------------

This seem very promising, so I guess a closer collaboration with them
would benefit everyone.


>> I agree with most of what you say above, but this is the world we live
>> in and try to be productive in. The same arguments can be used against
>> your company, suddenly someone offers you a billion EUR and then
>> the party is over.
>
> Which party is over?  When we started sysmocom, we made very sure that
> it does not control the Osmocom projects in any way.  It doesn't hold
> the trade marks, and all time Holger or I spent on development of
> Osmocom code is our personal copyright, and not that of a company.
> Also, there are no copyright assignments with contributors, making it a
> safe guard against anyone who might want to come later to try to change
> the license or whatever else.
>
> We have started sysmocom to be able to generate business that funds more
> developers and developments for Osmocom.

Awesome and very encouraging!


>> Seeing in general how things are developing with privately maintained FOSS,
>> I really think we should consider making some compromise. A good idea
>> would be to do the opposite of what you proposed, by making your GitHub
>> the offical repo and use instead your private as a mirror. As a FOSS you can
>> also have free private repos.
>
> I don't care where the primary git repository is hosted.  But  I do care
> about not using all the non-free issue tracking and merge request
> features of a proprietary service.
>
> This discussion has been taking a significant amount of time over the
> past days, and I think we have made both of our views sufficiently
> clear.

Very good and you have me convinced.
Thanks again for your time and I think it has been well spent.

Many Cheers,
E:V:A


From xdae3v3a at gmail.com  Tue Mar 21 14:40:05 2017
From: xdae3v3a at gmail.com (E:V:A)
Date: Tue, 21 Mar 2017 16:40:05 +0200
Subject: New hardware support or replacement proposal
In-Reply-To: <20170317150922.hw7biokgt4helslb@nataraja>
References: <CAFQZiU-u69uoh4qeccJr05zeo=+534r4S9q5weXs0KVkDcAnNw@mail.gmail.com>
 <20170317150922.hw7biokgt4helslb@nataraja>
Message-ID: <CAFQZiU8C14wwAVmGnjZ+F42M372u3UwRLSOViTKwkozyekLUVw@mail.gmail.com>

Dear Harald and Kevin,

Although, interesting from a purely academic view, you have both
already convinced me about the redundancy of using RPi for this
project. However, let me still respond to your answers.

On Fri, Mar 17, 2017 at 5:09 PM, Harald Welte <laforge at gnumonks.org> wrote:
> While a lot of microcontrollers have ISO7816 support in the UART, the
> hardware is designed in a way that restricts this to implementing the
> Reader-Side of ISO7816, and not the Card side - be alone a passive
> tracing.
>
> The requirements are subtly different between those modes, for example
> when it comes to
> * who is a master and who is a slave of the clock
> * being able to count the clock cycles to derive ETU and Waiting Time
>   from it
> * the card generates the ACK/NACK in case of partiy error, while the
>   reader or a sniffer doesn't
>
> So I am somewhat puzzled how you would want to do this (and do it
> "correctly" as per the ISO7816-1/-2/-3) with generic UARTs that have no
> ISO7816 moe to begin with?

I think its rather an academic interest in being able to push the
limits of popular embedded hardware. For example, the usage of RPi as
a successful FM (and 1000 Km range on HF) transmitter, is really
something exceptional. (All IMHO of course.) The more uses we can find
for these things, the more interest people will have to try out their
ideas.


>> There are too many advantages to ignore...
>> - The huge RPi developer community
>
> Who - no offence - most likely don't understand the intrinsics of
> ISO7186?  I don't want to be cynical, but if people wanted to contribute
> to the SIMtrace project, they could have done so in pure software, by
> simply extending/completing the wireshark dissectors beyond my initial
> code.  Until today, the contents of the EFs are not decoded, for
> example.  Would be great if the were, but they weren't.  I don't think
> this will change based on whether we use a Raspberry Pi or not on the
> hardware side.

Well a lot of security projects are using just the RPi3 and Zero for
testing all sorts of things, including using Wireshark for decoding
LTE and what not. Mostly for the reasons of simplicity, portability,
accessibility and low price.

>> - The high clockspeed and 512+ Mb of RAM
>
> Not sure that is an advantage?  Why is that an advantage?  We don't use
> most of the orders-of-magnitude lower RAM nor flash on the existing
> devices even in the past years.
>

The high clockspeed allow you to emulate various high speed interfaces
and dissect their protocols in real time.
The large RAM let you save loads of data reomtely as a IoT and lots
more, like a full native OS.

>> - All interfaces you can dream of, except JTAG
>
> ...and JTAG is probably the most useful interface you can have when
> implementing low-level code that's very close to hardware?

For complex devices like phones and TVs etc, Yes, but for THIS device
that only consist of 3 serial ports, I simply have no idea who would
use this and for what, after production.



>> - A huge reduction on the BOM. I've counted that we may remove about
>> 50 components by using this solution instead of the current v1.3 one.
>
> There's no problem with the BOM part count as-is?  Also.
>
>> - A huge reduction to about 1/3 of what is currently used of the PCB footprint.
>
> well, but then you have a RPi alongside with that, which is larger than
> the original PCB footprint
>
>> - A large reduction of production price due to above.
>
> not sure if the production cost difference really matters.

Well, to be anal about this, then you should also add the footprint
and price of your PC HW that you use to plugin to.The point here, was
that you would have one extremely small stand-alone computer that does
everything you currently do, but to half the price of the SIMtrace HW
itself.



>> - Easy to port drivers when understood
>
> Depends on what exact hardware interface you will come up to handle the
> ISO7816 lower layers.  The complexity is mostly in the ISO7816 state
> machines, and they won't change.
>
> And to be honest, I don't think an in-kernel-bitbanging
> implementation/driver of a ISO7816 soft-uart is going to be easy to
> understand (it just has to replicate what the SAMx hardware has), and it
> will particularly not be easy to develop and/or debug.

I can't argue with you on this point since I haven't even looked
enough into it. But, looking at the code for the ISO7816 labelled
bits, and knowing that there are a lot of already available I/F
bit-banging solutions for the RPi, is probably what triggered my
interest of this, in the first place.


>> The RPi's only has one UART so to get a second, we need to use
>> bit-banging of their GPIO,SPI or I2C. There are already solutions out
>> there and the much higher clock-rate of both devices allow you to run
>> up to 250 MHz on a single GPIO pin, so that would allow you to
>> multiplex a number of virtual/emulated UARTs. (Perhaps similarly to
>> what was already done when SIMtrace was using the FT232r?)
>
> Ok, so you'd be usign hihg-speed bit-banging and implement everyting in
> software, like a 'software defined ISO7816 UART'.   That's quite some
> coe that needs to be developed.

That was the idea. And since RPi is ARM and popular for all sorts of
other embedded devices. I  guess there ought to be a similar solution
out there already.


> Also, keep in mind that the SAM7/SAM3 support full industrial
> temperature range, which is not offered by consumer-grade devics like
> the Raspberry Pi.

This is an entertaining answer as RPis have been used as weather
stations in arctic climates where winter Temp can easily reach -20C. I
doubt you will find anyone doing any SIMtracing there. :)


> I really do appreciate your interest, but I am absolutely not convinced
> that this proposal is solving any actual problem or disadvangage.
>
> Rather than rebuilding what we alreay have based on different
> technology, I would much rather like to see people invest their time in
> extending what we already have.  This could be on the firmware side, but
> could also be on the hardware side.

I agree and as I said on top, you have me convinced. As for your other
comments, I think I already covered the relevant ones in the other
thread.

Thanks again for your team effort and support.

Cheers,
E:V:A


From laforge at gnumonks.org  Tue Mar 21 16:51:19 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 21 Mar 2017 17:51:19 +0100
Subject: New hardware support or replacement proposal
In-Reply-To: <CAFQZiU8C14wwAVmGnjZ+F42M372u3UwRLSOViTKwkozyekLUVw@mail.gmail.com>
References: <CAFQZiU-u69uoh4qeccJr05zeo=+534r4S9q5weXs0KVkDcAnNw@mail.gmail.com>
 <20170317150922.hw7biokgt4helslb@nataraja>
 <CAFQZiU8C14wwAVmGnjZ+F42M372u3UwRLSOViTKwkozyekLUVw@mail.gmail.com>
Message-ID: <20170321165119.nfuyvm7v5jcwos37@nataraja>

Hi E:V:A,

On Tue, Mar 21, 2017 at 04:40:05PM +0200, E:V:A wrote:
> > Ok, so you'd be usign hihg-speed bit-banging and implement everyting in
> > software, like a 'software defined ISO7816 UART'.   That's quite some
> > coe that needs to be developed.
> 
> That was the idea. And since RPi is ARM and popular for all sorts of
> other embedded devices. I  guess there ought to be a similar solution
> out there already.

I would be highly surprised.  You basically have to start from scratch.

> > Also, keep in mind that the SAM7/SAM3 support full industrial
> > temperature range, which is not offered by consumer-grade devics like
> > the Raspberry Pi.
> 
> This is an entertaining answer as RPis have been used as weather
> stations in arctic climates where winter Temp can easily reach -20C. 

Well, this may be the case, but there is one topic of using commercial
temperature rated equipment out of spec (which may work in many cases,
but may break in all kinds of ways, also from one production batch to
the other, because a different capacitor model/brand was used, and it
has a different thermal curve, which doesn't require the performance at
-20 or even down to -40 centigrade.  So basically "you are just lucky"

The other part is in professional industrial electronics development
(which I've been doing for quite some years, with interruptions), where
you make sure that all parts you use are fully qualified over the
industrial temperature range, and you cannot have the above-mentioned
surprises.

> I doubt you will find anyone doing any SIMtracing there. :)

You would be surprised.  Some people are using SIMtrace or related
devices as part of permanent installations in order to assess e.g.
cellular network security.

As much as I appreciate the enthusiasm, creativity and success of a lot
of the arduino/raspi/... based embedded projects that kome from the
wider maker community, there are quite some parts I don't like about it.
The lack of industrial tmeperature/climate spec on the one hand, the
incredibly complex and large software stack that might need to be
maintained.  The issue about using commercial-grade SD/MMC cards as
opposed to industrial-grade mmc (wit proper SMART-like features to get
advance notification of wear levelling statistics) or good old NOR flash
(SAM3), ...

> I agree and as I said on top, you have me convinced. 

Great!

So let's hope you can find some time and energy got help out.  As
indicated, I'm happy to send out some free SIMtrace with SAM3, or
alternatively you could help with (re)integrating the tracing
functionality in the simtrace2.x firmware branch, or porting the
simtrace2.x firmware to 1.x hardware, or work on wireshark dissectors,
...

-- 
- 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 laforge at gnumonks.org  Tue Mar 21 17:07:49 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 21 Mar 2017 18:07:49 +0100
Subject: Current status of the SIMtrace project
In-Reply-To: <CAFQZiU-6JfeeUZMtgdGL-CTDj9J13xH4zhE-eBzeqE2eph8hCQ@mail.gmail.com>
References: <CAFQZiU_ndM1WByE_JNgcdAJu229FqwfGqYDmRsHhcZV6wSexgw@mail.gmail.com>
 <20170316140134.7rgrhiswze2sdxyt@nataraja>
 <CAFQZiU_gE-SNg1uyNa3DKzifhX_Ny=kc_3pwUg5e0SyRWtJqyQ@mail.gmail.com>
 <20170317153934.5t22vj723galylkj@nataraja>
 <CAFQZiU-6JfeeUZMtgdGL-CTDj9J13xH4zhE-eBzeqE2eph8hCQ@mail.gmail.com>
Message-ID: <20170321170749.5bojdpgu7l2dpsti@nataraja>

Hi E:V:A,

On Tue, Mar 21, 2017 at 03:48:41PM +0200, E:V:A wrote:

> Thank you so much for taking the time to respond to all my inquiries
> and challenging comments/requests. Your response has indeed convinced
> me that this project is very much alive, but that it need a whole lot
> more of community TLC.

I'm not sure what TLC is? But yes, like most projects, we can use help
on various sides.

> No offense taken. They (bodziow and kamwar) just recently responded to
> my question here:
> https://github.com/kamwar/simLAB/issues/1
> and indeed thay have made several improvements.

Well, the problem that I see is that they have created a fork or done an
independent new implementation or something in between.  So rather than
working collaboratively with the existing project, and contributing
their work, they have created their own project.  Everyone is of course
free to do what they want, but it makes me somehow sad.  Have we ever
done something to them that made them go away?

The worst thing that a user wants is that there are 25 different
programs, all having different feature sets and different bugs, maybe
even based on different forks of some code made at some point in time.

>From a user point of view, you want one software in which everyone tries
contributes their bug fixes and feature enhancements.

And particularly, as we are talking about the firmware and host programs
separately, there should at least be some level of standardization on
the USB protocol, so that you have interoperability between the
in-device firmware and different host programs.

However, I haven't seen anyone showing up and proposing (let alone
implementing) a more flexible/standardized/future-proof USB protocol.

> This seem very promising, so I guess a closer collaboration with them
> would benefit everyone.

I do not recall ever having turned down any collaboration with anyone.
But collaboration is not "I silently take this code and make my own
version of it", but collaboration is to actively work together, to
submit proposals, code, comments, etc.

> > When we started sysmocom, we made very sure that
> > it does not control the Osmocom projects in any way.  It doesn't hold
> > the trade marks, and all time Holger or I spent on development of
> > Osmocom code is our personal copyright, and not that of a company.
> > Also, there are no copyright assignments with contributors, making it a
> > safe guard against anyone who might want to come later to try to change
> > the license or whatever else.
> >
> > We have started sysmocom to be able to generate business that funds more
> > developers and developments for Osmocom.
> 
> Awesome and very encouraging!

Thanks.  I would never do it any differently, and I guess anyone who has
been following some of my past work would see where my priorities are.

There are too many projects out there that are suffering (from my point
of view) of too much corporate/commercial influence.

Osmocom has existed before sysmocom came around (and hopefully will
exist after sysmocom is history?), and sysmocom is only involved in a
certain subset of projects.

> Thanks again for your time and I think it has been well spent.

I'm happy my feeling about this was right :)

-- 
- 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)