Hi EVA, nice to hear from the xda-developers hero ;) On Thu, Mar 16, 2017 at 03:04:50PM +0200, E:V:A wrote: great. 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. revision 1.4 (1.4p where 'p' is just for production) of the hardware has been current since 2014. 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. * 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 I don't recall having seen this before, so I cannot comment on it. there's just a lack of patches to integrate. If people on this list disagree, please let me know, by all means. 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? 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 &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

hi E:V:A, On Thu, Mar 16, 2017 at 05:53:30PM +0200, E:V:A wrote: likewise. I guess we've been working on different ends of cellular communications during the last decade but never really crossed roads. 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? 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) The 'p' is for 'production', kevin introduced that some time ago, I don't recall the exact rationale. 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. 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. 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 ;) 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. 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 :) 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. 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. 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. 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. No offence, but if you have an interest in such a comparison, I suggest you create it? Indeed. I guess nobody is used to receiving mails on this list anymore ;) good (first part) 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. 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. 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. 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 &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

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 &lt;laforge(a)gnumonks.org&gt; wrote: 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.. Good idea. 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) I knew you would mention this. ;) But that has quite a different project scope doesn't it... I agree, you have me convinced. 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. True and fair enough. I would be happy to deal with the documentation in case I ever get my hands on the new HW. 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. Awesome and very encouraging! 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