Hello mailing list,
I want to use the Simtrace for my master thesis on enhancing privacy in mobile networks. For this purpose I recently bought 2 Simtraces. However I have a few questions:
Which firmware is on newly shipped Simtraces? The "buggy" v0.5 or the community enhanced version?
Also I wanted to flash new firmware to the device (both from simlabtrace (https://github.com/kamwar/simlabTrace/wiki), as well as newly compiled firmware from git repository (git://git.osmocom.org/openpcd.git). I wasn't able to try the community fix since the url(http://lists.osmocom.org/pipermail/simtrace/attachments/20140624/a17d1070/at...) is down. The flashing process itself freezes after checking the connection state of the device. Even though the device is listed as idle the process does not continue. Any idea why? I'm working on a fresh and updated Kali Linux. If it's the OS do you have any suggestion for using another?
If the support/development of the Simtrace is at an end can you recommend similar devices?
Greetings, Michael Kramer
On 13 Oct 2016, at 11:17, Michael Kramer michael.kramer@uni-konstanz.de wrote:
Hello mailing list,
Hi Michael!
I want to use the Simtrace for my master thesis on enhancing privacy in mobile networks. For this purpose I recently bought 2 Simtraces. However I have a few questions:
great. will you (or did you already) publish parts of your work?
Which firmware is on newly shipped Simtraces? The "buggy" v0.5 or the community enhanced version?
I don't know which firmware version is used when flashing but I find that question funny. "community buggy" vs. "community enhanced"? There is the Osmocom community and it works by people collaborating. You are free to contribute your time and work towards a new "non-buggy" "community" release.
Also I wanted to flash new firmware to the device (both from simlabtrace (https://github.com/kamwar/simlabTrace/wiki), as well as newly compiled firmware from git repository (git://git.osmocom.org/openpcd.git). I wasn't able to try the community fix since the url(http://lists.osmocom.org/pipermail/simtrace/attachments/20140624/a17d1070/at...) is down. The flashing process itself freezes after checking the connection state of the device. Even though the device is listed as idle the process does not continue. Any idea why? I'm working on a fresh and updated Kali Linux. If it's the OS do you have any suggestion for using another?
I don't know what simlabTrace is and with my 90s Free Software hat on, I would prefer if people collaborate more again, instead of going into their own corner.
The original lists.osmocom.org went down and was replaced but we have filled the archives with old mail. Apparently links have changed but if you go to 06.2014 you will find the original mail and the attachment can be downloaded.
If the support/development of the Simtrace is at an end can you recommend similar devices?
There are proprietary alternatives if you prefer such things. I would prefer if you take some of your time to help to make Osmocom's SIMtrace better.
thank you holger
Am Donnerstag, 13. Oktober 2016 11:44 CEST, Holger Freyther holger@freyther.de schrieb:
On 13 Oct 2016, at 11:17, Michael Kramer michael.kramer@uni-konstanz.de wrote:
Hello mailing list,
Hi Michael!
Hello Holger, thank you for that quick reply!
I want to use the Simtrace for my master thesis on enhancing privacy in mobile networks. For this purpose I recently bought 2 Simtraces. However I have a few questions:
great. will you (or did you already) publish parts of your work?
I'm just starting with the corresponding project for my thesis and have not done any actual coding yet. Just trying to get to know Simtrace and everything to be able to work with it. However I plan on publishing every result I can get.
Which firmware is on newly shipped Simtraces? The "buggy" v0.5 or the community enhanced version?
I don't know which firmware version is used when flashing but I find that question funny. "community buggy" vs. "community enhanced"? There is the Osmocom community and it works by people collaborating. You are free to contribute your time and work towards a new "non-buggy" "community" release.
Well the 0.5 available on the wiki is from 2012. And there is the "0.5.3-6ea9-dirty" firmware I've found through reading the mailing list archive which should fix some problems.
Also I wanted to flash new firmware to the device (both from simlabtrace (https://github.com/kamwar/simlabTrace/wiki), as well as newly compiled firmware from git repository (git://git.osmocom.org/openpcd.git). I wasn't able to try the community fix since the url(http://lists.osmocom.org/pipermail/simtrace/attachments/20140624/a17d1070/at...) is down. The flashing process itself freezes after checking the connection state of the device. Even though the device is listed as idle the process does not continue. Any idea why? I'm working on a fresh and updated Kali Linux. If it's the OS do you have any suggestion for using another?
I don't know what simlabTrace is and with my 90s Free Software hat on, I would prefer if people collaborate more again, instead of going into their own corner.
I've also found simlabTrace through the mailing list. He published his work there and I went on github to check and try it out.
The original lists.osmocom.org went down and was replaced but we have filled the archives with old mail. Apparently links have changed but if you go to 06.2014 you will find the original mail and the attachment can be downloaded.
Got it! However the flashing process still freezes after checking the device status... Any suggestions towards that problem? Might try with a different OS.
If the support/development of the Simtrace is at an end can you recommend similar devices?
There are proprietary alternatives if you prefer such things. I would prefer if you take some of your time to help to make Osmocom's SIMtrace better.
Will try my best to do that!
Greetings, Michael
On 13 Oct 2016, at 12:32, Michael Kramer michael.kramer@uni-konstanz.de wrote:
Which firmware is on newly shipped Simtraces? The "buggy" v0.5 or the community enhanced version?
I don't know which firmware version is used when flashing but I find that question funny. "community buggy" vs. "community enhanced"? There is the Osmocom community and it works by people collaborating. You are free to contribute your time and work towards a new "non-buggy" "community" release.
Well the 0.5 available on the wiki is from 2012. And there is the "0.5.3-6ea9-dirty" firmware I've found through reading the mailing list archive which should fix some problems.
origin/master of SIMtrace has Min Xu's patches. Not sure if anyone has validated them.
Got it! However the flashing process still freezes after checking the device status... Any suggestions towards that problem? Might try with a different OS.
What do you flash? Do you use SAM-BA/sam7utils to flash everything or use dfu-util to update the app? Which version of sam7utils or dfu-utils do you use?
holger
Am Donnerstag, 13. Oktober 2016 20:56 CEST, Holger Freyther holger@freyther.de schrieb:
What do you flash? Do you use SAM-BA/sam7utils to flash everything or use dfu-util to update the app? Which version of sam7utils or dfu-utils do you use?
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine. Haven't used SAM-BA yet. Should I try that as well?
Michael
On 14 Oct 2016, at 08:46, Michael Kramer michael.kramer@uni-konstanz.de wrote:
Am Donnerstag, 13. Oktober 2016 20:56 CEST, Holger Freyther holger@freyther.de schrieb:
What do you flash? Do you use SAM-BA/sam7utils to flash everything or use dfu-util to update the app? Which version of sam7utils or dfu-utils do you use?
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine. Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could you try an older version of dfu-utils? E.g. I started with dfu-utils and probably still have this version around.
holger
Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther holger@freyther.de schrieb:
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine. Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could you try an older version of dfu-utils? E.g. I started with dfu-utils and probably still have this version around.
Could you maybe check which version it was?
-Michael
On 16 Oct 2016, at 22:15, Michael Kramer michael.kramer@uni-konstanz.de wrote:
Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther holger@freyther.de schrieb:
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine. Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could you try an older version of dfu-utils? E.g. I started with dfu-utils and probably still have this version around.
Could you maybe check which version it was?
oh. I did and then didn't write it down. It was dfu-util 0.4 that I have used in the past.
holger
Hi Michael,
Just to let you know dfu-util 0.9 didn't worked for me either, but SAM-BA/sam7utils did!
I just followed this simtrace wiki page instructions to do so (flashing using libusb): https://osmocom.org/projects/simtrace/wiki/SIMtrace_Firmware The wiki page has the firmware attached in the format required by SAM-BA. I compiled it myself with the arm toolchain, though. The tricky part was switching to SAM-BA mode, what the wiki page says is true: sometimes it just not works ... After 3 or 4 attempts it worked.
I hope this helps. Regards.
2016-10-16 22:28 GMT+02:00 Holger Freyther holger@freyther.de:
On 16 Oct 2016, at 22:15, Michael Kramer michael.kramer@uni-konstanz.de
wrote:
Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther <
holger@freyther.de> schrieb:
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine.
Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could you
try an older version of dfu-utils? E.g. I started with dfu-utils and probably still have this version around.
Could you maybe check which version it was?
oh. I did and then didn't write it down. It was dfu-util 0.4 that I have
used in
the past.
holger
-- J. Félix Ontañón Director of R&D Podsystem Group
Hey Felix,
thank you for your answer! However since holger recommended dfu-util 0.4 I tried the 0.5 version since 0.4 was not available on the website. With the 0.5 version it works. Hope this helps you as well since it's easier to flash.
Greetings, Michael
Am Dienstag, 08. November 2016 17:47 CET, J. Félix Ontañon felix.ontanon@podsystem.com schrieb:
Hi Michael,
Just to let you know dfu-util 0.9 didn't worked for me either, but SAM-BA/sam7utils did!
I just followed this simtrace wiki page instructions to do so (flashing using libusb): https://osmocom.org/projects/simtrace/wiki/SIMtrace_Firmware The wiki page has the firmware attached in the format required by SAM-BA. I compiled it myself with the arm toolchain, though. The tricky part was switching to SAM-BA mode, what the wiki page says is true: sometimes it just not works ... After 3 or 4 attempts it worked.
I hope this helps. Regards.
2016-10-16 22:28 GMT+02:00 Holger Freyther holger@freyther.de:
On 16 Oct 2016, at 22:15, Michael Kramer michael.kramer@uni-konstanz.de
wrote:
Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther <
holger@freyther.de> schrieb:
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine.
Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could you
try an older version of dfu-utils? E.g. I started with dfu-utils and
probably still have this version around.
Could you maybe check which version it was?
oh. I did and then didn't write it down. It was dfu-util 0.4 that I have
used in
the past.
holger
Good to know. I'll give a try dfu-util 0.5 next time. You're right: SAM-BA made me loose so much time.
2016-11-10 13:34 GMT+01:00 Michael Kramer michael.kramer@uni-konstanz.de:
Hey Felix,
thank you for your answer! However since holger recommended dfu-util 0.4 I tried the 0.5 version since 0.4 was not available on the website. With the 0.5 version it works. Hope this helps you as well since it's easier to flash.
Greetings, Michael
Am Dienstag, 08. November 2016 17:47 CET, J. Félix Ontañon < felix.ontanon@podsystem.com> schrieb:
Hi Michael,
Just to let you know dfu-util 0.9 didn't worked for me either, but SAM-BA/sam7utils did!
I just followed this simtrace wiki page instructions to do so (flashing using libusb): https://osmocom.org/projects/simtrace/wiki/SIMtrace_
Firmware
The wiki page has the firmware attached in the format required by
SAM-BA. I
compiled it myself with the arm toolchain, though. The tricky part was switching to SAM-BA mode, what the wiki page says is true: sometimes it just not works ... After 3 or 4 attempts it worked.
I hope this helps. Regards.
2016-10-16 22:28 GMT+02:00 Holger Freyther holger@freyther.de:
On 16 Oct 2016, at 22:15, Michael Kramer <
michael.kramer@uni-konstanz.de>
wrote:
Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther <
holger@freyther.de> schrieb:
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine.
Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could
you
try an older version of dfu-utils? E.g. I started with dfu-utils and
probably still have this version around.
Could you maybe check which version it was?
oh. I did and then didn't write it down. It was dfu-util 0.4 that I
have
used in
the past.
holger
- Re: Basic questions (Michael Kramer)
- Very basic questions (?? ???)
- Re: Basic questions (J. F?lix Onta?on)
- Re: Very basic questions (Holger Freyther)
---------- Forwarded message ---------- From: Michael Kramer michael.kramer@uni-konstanz.de To: "J. Félix Ontañon" felix.ontanon@podsystem.com Cc: simtrace@lists.osmocom.org Date: Thu, 10 Nov 2016 13:34:18 +0100 Subject: Re: Basic questions Hey Felix,
thank you for your answer! However since holger recommended dfu-util 0.4 I tried the 0.5 version since 0.4 was not available on the website. With the 0.5 version it works. Hope this helps you as well since it's easier to flash.
Greetings, Michael
Am Dienstag, 08. November 2016 17:47 CET, J. Félix Ontañon < felix.ontanon@podsystem.com> schrieb:
Hi Michael,
Just to let you know dfu-util 0.9 didn't worked for me either, but SAM-BA/sam7utils did!
I just followed this simtrace wiki page instructions to do so (flashing using libusb): https://osmocom.org/projects/simtrace/wiki/SIMtrace_
Firmware
The wiki page has the firmware attached in the format required by
SAM-BA. I
compiled it myself with the arm toolchain, though. The tricky part was switching to SAM-BA mode, what the wiki page says is true: sometimes it just not works ... After 3 or 4 attempts it worked.
I hope this helps. Regards.
2016-10-16 22:28 GMT+02:00 Holger Freyther holger@freyther.de:
On 16 Oct 2016, at 22:15, Michael Kramer <
michael.kramer@uni-konstanz.de>
wrote:
Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther <
holger@freyther.de> schrieb:
I've tried both dfu-utils 0.8 and 0.9 on a debian and kali machine.
Haven't used SAM-BA yet. Should I try that as well?
SAM-BA is a lot more inconvenient and slower than dfu-utils. Could
you
try an older version of dfu-utils? E.g. I started with dfu-utils and
probably still have this version around.
Could you maybe check which version it was?
oh. I did and then didn't write it down. It was dfu-util 0.4 that I
have
used in
the past.
holger
ATMEL chip document [see section 7.2] states (and my experience confirming this is) that TST, PA0, PA1 and PA2 should be tied high. On the next cycle, SAMBA will be booted into (this is SAM-BA boot recovery). To do that, you jumper it just like SIMTRACE wiki states, but do not need to press a button. On the specific chip used, that means you take a tweezer and short PIN 44/45 with pin 47/48. That means one tip if the tweezer sits between pin 44 and pin 45 (PA2 and VDDIO[high]), and the other tip of the tweezer sits between pin 47 and pin 48 (PA1 and PA0)
MAKE SURE YOU DO NOT TOUCH OTHER PINS. Pin 46 is Ground. It would not be good to short between 45 and 46.
Once you have your tweezer in place and the jumper in place, power up the board (should be able to hold the tweezer and board with one hand resting on it) by plugging in the USB cable. Leave it powered up for about 20 seconds (it recovers -- flashes itself), then power off, remove the jumper, remove the tweezer. Then when you plug the USB back in, it'll be ready for SAM-BA programming.
Maybe someone can add this to the wiki?
-
Holger Freyther -
J. Félix Ontañon -
Michael Kramer -
Min Xu