This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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)