simtrace January 2014

simtrace@lists.osmocom.org

13 participants
6 discussions

Incomplete trace (due to high-speed SIM?)
by Min Xu 19 Nov '14

19 Nov '14

*Holger Hans Peter Freyther* holger at freyther.de <simtrace%40lists.osmocom.org?Subject=Re%3A%20Incomplete%20trace%20%28due%20to%20high-speed%20SIM%3F%29&In-Reply-To=%3C20130522102301.GP14728%40xiaoyu.lan%3E> *Wed May 22 12:23:01 CEST 2013* | On Tue, May 21, 2013 at 03:53:45PM +0200, Arthur Léna wrote: | >* I tried booting the iPhone using 2 different SIMs (this one from * | >* Free Mobile and another one) and the trace seems very short using | *>* the Free Mobile in comparison to the other one. By parsing the ATRs | *>* of both SIMs, I found out that the communication is done at 312500 | *>* bits/s with the Free Mobile SIM and only 78125 bits/s (for a clock | *>* running at 5MHz). Could this explain the loss of entire ADPUs by the * | >* tracer? If yes, is there a way to remedy to this problem (firmware * | >* update for example). *| Some people reported success by reducing the size of buffered bytes in the | firmware. | holger Holger There appears to be numerous references to "decrease the buffer in the firmware" to workaround the problem of losing bytes... but can you clarify which buffer to decrease, in which source file? I am guessing it's the req_ctx.c / req_ctx.h? Thanks

7 19

Fast SIM cards loosing bytes
by Dean Chester 25 Jun '14

25 Jun '14

Hi, I see earlier in the archives that reducing the buffer size in the firmware will resolve this. Hasn't this already been done though in new releases of the firmware? As I have pulled the latest version from the openpcd git repo and built it. If not what have people reduced the buffer size to? And has it had any fixes? Sent from my iPad

5 14

Detecting "Silent SMS" with Simtrace
by Mell Kuss 24 Jan '14

24 Jan '14

2 1

[RFC] [ADMIN] Making lists subscriber-only?
by Harald Welte 15 Jan '14

15 Jan '14

Dear all, so far the osmocom.org mailing lists have always been in a 'non-members are manually moderated' mode. This has created a lot of work for manual list moderation, where a lot of the messages caught are simply spam, and only the occasional valid message is being received. I'd like to thank the list moderators for taking care of this. However, in more recent discussions, we were considering to move the lists to a completely closed mode, i.e. postings would automatically be rejected from non-members. The automatic response would contain a description of how to subscribe in 'nomail' mode, i.e. to subscribe in a way to be able to post to the list, while still not receiving any incoming traffic. The latter should be fine for occasional posters who don't want the bulk e-mail that goes with a full/regular subscription. Please provide feedback in case you disagree with that change. Unless there is major opposition, we will likely transition to the 'closed' mode within one month. Thanks, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 6

DFU mode, wireshark
by Martin Kaiser 13 Jan '14

13 Jan '14

Dear all, recently, we added a dissector for USB DFU to wireshark. It recognizes packets based on product ID + vendor ID. I tested this with my simtrace (v1.0) board and it works like a charm when I add 0x16c0, 0x0762. However, I saw that for the simtrace board, prod id/vendor id is the same for DFU mode and sniffer mode. I guess that for sniffer mode (or any other mode than DFU), it doesn't really make sense to capture the raw USB packets. Therefore, I tend to add 0x16c0, 0x0762 and link it to USB DFU. Are you ok with this? Thanks, Martin

2 1

OsmoDevCon 2014 / Date / Venue
by Harald Welte 02 Jan '14

02 Jan '14

Hi all, time is moving fast, and I want to start some initial discussion and planning for OsmoDevCon 2014. There are basically four questions which I'm raising below. Please provide your feedback to the osmocom-event-orga mailing list only, to avoid cross-posting over all the project lists. = Who? = My intention is to keep it an 'active developer/contributer only' event, like we had it before. I would also want to keep the group relatively small, to keep the 'Osmocom family' atmosphere. If desired, we could have one half or full day of public prsentations in a larger auditorium, but the developer meeting should be a close group, as known so far. = Where? = If we keep the number of attendees within the same range as this year, then I'm sure we could again hold it at the same venue. I know it is not perfect, but it is a place that we have access to, 24 hours per day, and free of cost for community projects like osmocom.org. If the community wants a larger event, then this is something that would require more funds and much more time organizing. And that is something that I personally could not offer to take care of, sorry. I'm happy to attend and support any larger events, but I'm unable to take care of fundraising and venue research. = When? = Q1/2014. In January, I'm not aware of any 'blocker' events. February, there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg March 17-21). Did I miss any other FOSS / mobile event that might clash in Q1? So my preference woudl be to do it either late January (23-26) or in February (6-9 or 13-16). Any preferences regarding preferred schedule? Once we have some concencus here on the list [and we want to do it in the same size / venue], I'll talk to IN-Berlin. = What? = I think that question is easy to answer, if we have the above three figured out... There's no shortage of topics, I suppose. You can start adding your suggestions to http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace January 2014