simtrace

simtrace@lists.osmocom.org

346 discussions

SAM3 DFU
by Thomas Chen 30 Nov '17

30 Nov '17

question about DFU... working with AT91SAM3 board, i tried, 1. use sam-ba to flash the DFU image (works fine) 2. try to use dfu-util to flash the APP, but it does not seem to write into flash (after reboot we still have the initial DFU image ??) (i am using the same argument as SAM7 -a0 -D filename -R is there any tips you can provide before i start digging ?

3 2

remote sim network delay
by Thomas Chen 27 Nov '17

27 Nov '17

i am not clear about how simtrace2, specifically libcommon/source/card_emu.c seems to handle the network delay for remote sim response however, i dont understand how that would help ??? my understand of the protocol is that ME => SIM (first 5 bytes of APDU) SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol) but that does not help remote sim, as remote SIM would need the susequent bytes which will not come until we send back INS, so just holding off ME with 0x60 does not alleviate the problem of network delay

4 6

Min Xu patches testing (Lukas Kuzmiak)
by Min Xu 03 Nov '17

03 Nov '17

Hi Lukas I saw your email to my @sanjole.com address but since this address is on the mailing list I'll just reply here so everyone can see. --- your email below --- Hi Min Xu, first of all thanks for all the work you put into simtrace. I’ve been testing your patches last couple days, they have not yet been in any release which I think is a shame, so I’d like to push the community to fix that so it can be even further tested (by testing, reporting back, fixing building the firmware with latest arm-none-eabi, etc.) I have found one bug for which I fail to identify the source .. The whole trace is fine except sometimes there are 4 bytes inside the data which seems to be the simtrace_hdr (first line is my debug): USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04 02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03 30 10 66 03 91 12 90 00 APDU: 00 a4 00 04 02 6f 07 61 2a APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 APDU: 01 00 09 05 00 b0 00 APDU: 00 09 b0 08 29 03 30 APDU: 10 66 03 91 12 90 00 The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5) just randomly appear in APDU data every now and then. If those 4 bytes were not there apdu_split would split it fine .. like this it breaks this into nonsense pieces and breaks the trace. I’ve gone through your patches in the firmware, fiddled around with some of them but didn’t manage to find the root cause yet - seems like the simtrace_hdr is inserted in the middle (but that does not seem possible), so perhaps 2 USB messages somehow get merged into one? So I figured I’ll try to write you, maybe it will ring a bell - I have not fully verified the merge of your patches went correctly but from a fast compare it seems like it. If you’ll find a minute to give me a few tips I’ll appreciate that, in the meantime I’ll keep digging. PS: the version of FW I’m using is latest master in the git (https://git.osmocom.org/openpcd). Thanks! Lukas --- END --- I believe the reason for this is actually in an email I sent to the list on Sep 10, 2013. Basically, the ATMEL chip can break up the req_ctx ( the usb response ) and combine as it see fit (if there's a large burst etc). So you cannot rely on the "natural break" between the calls to transmit. Therefore, since it's a stream you'll get on receiving side, then a natural packet header that accounts of subsequent bytes must be added. So I added extra bytes into the simtrace_hdr header so that the actual data payload can be correctly accounted for. The changes are: struct simtrace_hdr { u_int8_t cmd; u_int8_t flags; u_int8_t res[2]; + u_int16_t seq_num; + u_int16_t offset; + u_int16_t tot_len; u_int8_t data[0]; } __attribute__ ((packed)); So the desktop client will have to have equivalent changes to account for these extra fields. Let me know if this answers your question. If not I can try send you the full code I have for the firmware and a sample of the desktop receiving / parsing code so you'll have a baseline.

2 2

Min Xu patches testing
by Lukas Kuzmiak 03 Nov '17

03 Nov '17

Hi again guys, I've been testing the latest firmware (git master) to see how patches from Min Xu made it better and tracing of fast sims (lost bytes, broken tracing, etc.) seems to be a lot improved. I have found one bug - somehow simtrace_hdr makes it into the APDU payloads, I've been trying to find the root cause of this but have not managed yet - seems like the FW sends 2 messages but they arrive as a single message into the host software thus the header is considered APDU payload. I've reported the issue here: https://osmocom.org/issues/2614 along with all the tracing/investigation I've performed so far - anybody got further ideas how this might happen? Other than this and the painful building of the firmware in today's world it seems tracing modern phones is not such a pain as it used to be, yay! Lukas

1 0

building simtrace FW nowdays
by Lukas Kuzmiak 03 Nov '17

03 Nov '17

Hi guys, after a long time I blew the dust off of mine SIMtrace 1.0p, went through the history of the mailing list archives and saw there were some nice fixes for fast sims but there is no released firmware that includes them (v0.5 is latest dated in 2012 - I still have some sync issues/lost bytes with v0.5 like i used to years ago). So I got to building and oh boy :-) Back in the day arm-elf was not obsolete and all went fine, today with arm-none-eabi however, not so much. After couple days of fiddling around with building custom toolchains, trying the ones from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads <https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads> and other goodies I realized I keep running into the same issue over and over again. Some kind of a weird boot loop - see UART log attached. Weirdly enough the DFU compiles fine with the gcc-arm-none-eabi-6-2017-q2-update toolchain and works just fine, it seem main_simtrace also compiles, links and even starts initializing but then dies somewhere in the middle. I never got pass this "[00001E] computed Fi(1) Di(1) ratio: 372” to “ISO_SW Initializing” .. Have not managed to figure out why - any help appreciated on this. In the end I went all the way back to gcc-4.6.4, had to apply some patches do it’d compile on a recent Debian (9.2) .. and using arm-elf toolchain produces a working firmware (after reverting commit 373c172ab858102e1818c8476ab1a2b290685cda "convert from u_int*_t to uint*_t”). For anybody in this situation see the procedure below (for reference). Hopefully the issue can be collaboratively fixed - I’m happy to test around on 1.0p and 1.4p boards, different toolchains etc. but I don’t really know how to debug the bootloop - even a nudge in that is appreciated. Btw - is it possible to get write access to SIMtrace wiki? There’s a bunch of stuff that could be fixed :) eg. i had to dig sam7utils from archive.org <http://archive.org/> (openpcd.org <http://openpcd.org/> no longer has it) and some other misc stuff. IMHO if this can be fixed a v0.6 release could be made after (or even before) to bring those fast sim features to people in a simpler fashion? I have yet to test that functionality on my end - I can report back on how it seems to perform (not sure how widely tested it has been). Lukas GCC-4.6.4 (arm-elf) on Debian 9.2: - use the gnu-arm-build.3.sh script from https://osmocom.org/projects/baseband/wiki/GnuArmToolchain <https://osmocom.org/projects/baseband/wiki/GnuArmToolchain> - apply a patch below to the script, gcc.patch is https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00375.html <https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00375.html>, gcc.texi.patch is https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html <https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html> - voila, compile simtrace firmware (git revert —no-commit 373c172ab858102e1818c8476ab1a2b290685cda - if you’re using master). 8,9c8,9 < GCC_SRC=gcc-4.8.2.tar.bz2 < GCC_VERSION=4.8.2 --- > GCC_SRC=gcc-4.6.4.tar.bz2 > GCC_VERSION=4.6.4 20c20 < TARGET_TRIPLET=arm-none-eabi --- > TARGET_TRIPLET=arm-elf 69a70,78 > > # > # Stage 0: Patch the old gcc so it compiles on modern systems > # > ( > cd $SRCDIR/$GCC_DIR > patch -p1 < ../../gcc.patch > patch -p1 < ../../gcc.texi.patch > ) || exit 1

1 0

Want to do paid work on Osmocom? sysmocom is hiring
by Harald Welte 31 Oct '17

31 Oct '17

Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to jobs(a)sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwelte(a)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 * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

new APDU command - how?
by Ale Ch 31 Oct '17

31 Oct '17

Hi! Tell me please, how to add new APDU command discription to see it in Wireshak log? Where in source code lay this command description? regards Alex

2 1

can't open USB device
by Ale Ch 26 Oct '17

26 Oct '17

Dear collegues, could you help me to start using SIMtrace board? I have bought SIMtrace board v1.4 from symocom shop. I have got sources from github but cannot (it is strange) built user manual on my ubuntu computer. BUT I am successfully built simtrace application but it cannot recognize the board. >user@lnkd149:~/OSMOCOM/simtrace/host$ ./simtrace >simtrace - GSM SIM and smartcard tracing >(C) 2010 by Harald Welte <laforge(a)gnumonks.org> > >can't open USB device that message I have received on my screen... Could you advise something? regards Alex

2 2

Planning for OsmoCon + OsmoDevCon
by Harald Welte 14 Oct '17

14 Oct '17

[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org] Dear all, time is flying, and I would like to start early with discussions and planning about OsmoCon and OsmoDevCon in 2018. It helps to start early. Side note: We have some pending issues about the events from last year at http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them in the text below. == OsmoDevCon == For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as every year, which means: * same venue, same catering options * same concept of 'anyone contributing to Osmocom can apply for registration until all seats are taken' * same idea of inviting some few speaker[s] doing other FOSS mobile communications work to join us The parts that we need to change, IMHO: * don't reduce from 4 to 3 days like last year. Have full 4 days again * sort topics per day / half-day, i.e. have "GSM/UMTS Cellular Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co, but then have other days for other projects. This would enable people not interested in the [continued evolvement] of the cellular projects be able to skip those days, or to simply meet in an adjacent room for parallel hacking sessions/discussions * try to be a bit more structured with the schedule in general. The existing approach works for people who attend all the event all day long, but not so well for people with other plans / limited time Any further change requests or topics to discuss? Please note that Pablo Neira has offered to kindly host an OsmoDevCon in Seville (Spain). I've attended a number of netfilter workshops he organized there, and he's doing a great job! However, given the large number of attendees from Berlin (and Germany in general), I think this would make things more complicated, and more expensive for most attendees. If you disagree with that assessment: I'm open for having the discussion, I just thought it's more practical/economic to do it in Berlin. === 10 year Anniversary Party === Given that 2018 marks the 10 year anniversary of Dieter and me hacking with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves some special celebration of some form. I have no concrete idea yet, but for sure we should so something, and it should be at/around OsmoDevCon. And for sure we should have a BS-11 around :) == OsmoCon == The public OsmoCon was welcomed and was a success. However, let's start this discussion with a review of last years event. === Registration === * Registrations came in way too late. Two weeks ahead of the event, we were considering to cancel it. And then within the last few days, we had to turn people down due to limited seating capacity * To make planning more reliable, we see on other option but to significantly raise the registration fee combined with an equally significant discount for early booking === Duration === * Many people requested multiple days rather than just one, in order to make more out of (long distance) travels. This is obvious, but as we had no idea how many people would attend at all (or if we have to cancel due to lack of attendance), planning multiple days in the first incarnation would have been high risk and a multitude of work * I would suggest to expand to two or even three days this week, possibly one days with tutorials and the other day with tech talks * Slightly less crammed schedule due to multiple days === Venue === We recognize this yearso venue was not the best option, due to * Bad ventilation in the basemenet * Difficult to find * No space next to the conference room where people can meet / hang out in parallel to talks (not everyone attends every talk) I still like the "understatement" of the venue. I'd prefer any hostel / non-profit / hackerspace / university over luxurious hotels any time. Going to an expensive venue means more or less automatically more expensive ticket fees, which again is more likely to exclude pure community members without a commercial activity related to Osmocom. So any future venue would ideally: * be able to hold slightly more people than this year * have a second room or large lobby in which people can meet for extended coffee breaks in parallel to some talks, as needed * be slightly easier to find (and we have to put up some signs outside and in the lobby) * have better WiFi and/or wired connectivity === Programme / Format === * less crammed over multiple days * some more "interactive" formats were requested, for users to provide feedback to developers * there was some discussion about topics / speakers in redmine last year, but not too much participation [until it was too late]. * I'd suggest a more formal CfP process with a submission deadline that allows us to publish a preliminary schedule long ahead of the event === Video Recordings === I think they were a big success, and it was a very big surprise that the CCC Video Operations Center was volunteering to help such a small and niche-interest event like OsmoCon. We should make sure that we can repeat this for 2018. == Dates / Frequency == Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at a full week for those of you who would like to attend both events. But then, I think the number of people attending both events is actually not all that big. Without checking the details, I think not more than half of the OsmoDevCon attendees were attending OsmoCon. I would expect that tendency to remain or even increase. I still think it's good to keep them back-to-back. In terms of frequency, I would actually suggest we move to a 6-month cycle rather than a 12-month cycle. There's a lot of development going on at all time. I understand that not everyone is able to attend two events just on Osmocom, especially if it's a spare time / hobby type activity. That's ok, I think there's no problem with attending either of the two only, and catching up by video recordings and/or mail on the other. The qeustion is: Should that second event be developer-oriented or user-oriented? Or again both? Any comments here? Ok, that was a somewhat lengthy e-mail. Please make sure to provide any feedback you may have as early as possible, to increase the chances of your feedback being reflected in the planning. Happy hacking, 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 0

[PATCH] firmware: Makefiles: enable changing toolchain
by Denis 'GNUtoo' Carikli 05 Oct '17

05 Oct '17

Without that the user was expected to either patch the Makefiles or to get a toolchain with the arm-elf- prefix. Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> --- firmware/Makefile | 13 +++++++------ firmware/Makefile.dfu | 13 +++++++------ 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/firmware/Makefile b/firmware/Makefile index 350b0dc..1581a1f 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -352,12 +352,13 @@ LPC21ISP_CONTROL = -control # Define programs and commands. SHELL = sh -CC = arm-elf-gcc -CPP = arm-elf-g++ -OBJCOPY = arm-elf-objcopy -OBJDUMP = arm-elf-objdump -SIZE = arm-elf-size -NM = arm-elf-nm +CROSS_COMPILE ?= arm-elf- +CC = $(CROSS_COMPILE)gcc +CPP = $(CROSS_COMPILE)g++ +OBJCOPY = $(CROSS_COMPILE)objcopy +OBJDUMP = $(CROSS_COMPILE)objdump +SIZE = $(CROSS_COMPILE)size +NM = $(CROSS_COMPILE)nm REMOVE = rm -f COPY = cp diff --git a/firmware/Makefile.dfu b/firmware/Makefile.dfu index 3c797ef..1e9e71c 100644 --- a/firmware/Makefile.dfu +++ b/firmware/Makefile.dfu @@ -303,12 +303,13 @@ LPC21ISP_CONTROL = -control # Define programs and commands. SHELL = sh -CC = arm-elf-gcc -CPP = arm-elf-g++ -OBJCOPY = arm-elf-objcopy -OBJDUMP = arm-elf-objdump -SIZE = arm-elf-size -NM = arm-elf-nm +CROSS_COMPILE ?= arm-elf- +CC = $(CROSS_COMPILE)gcc +CPP = $(CROSS_COMPILE)g++ +OBJCOPY = $(CROSS_COMPILE)objcopy +OBJDUMP = $(CROSS_COMPILE)objdump +SIZE = $(CROSS_COMPILE)size +NM = $(CROSS_COMPILE)nm REMOVE = rm -f COPY = cp -- 2.14.1

2 1

← Newer
1
...
12
13
14
15
16
17
18
...
35
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace