From laforge at gnumonks.org  Sat Dec 10 19:11:39 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Dec 2016 20:11:39 +0100
Subject: RFC: OsmoDevCon 2017 planning
Message-ID: <20161210191139.rxtzqrdmsifwgi4s@nataraja>

Dear Osmocom Community,

[please respect the Reply-To and post all follow-up discussion to this
 to openbsc at lists.osmocom.org, so we avoid having long threads
 cross-posted to several mailing lists.]

>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences.  Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.

This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.

On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users.  And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.

Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.

So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties.  I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.

One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.

Another idea would be to split into a 'user day' and 'developer days'
format.  This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software.  The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.

Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.

One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?

What is the general opinion about this?

Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?

In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany.  But I'm of course very happy if somebody wants to
host it some place else...

Regards, and looking forward to meeting you [again] in 2017,
	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)


From joranglequeen at sina.com  Tue Dec 13 13:22:13 2016
From: joranglequeen at sina.com (joranglequeen at sina.com)
Date: Tue, 13 Dec 2016 21:22:13 +0800
Subject: Some Questions about Simtrace
Message-ID: <20161213132213.E902638053A@webmail.sinamail.sina.com.cn>

 Dear Sir or Madam:	I've bought two simtrace development boards two months ago in order to research the communication between the SIM-card and the mobile phone. However, recently when I need to analyse the packet which contains CK and IK, I sadly found that the packet was not captured every time. Mostly it returns as a malformed packet in the wireshark, which blocks my future studying. I read the user manual and it says that for some high speed cards the firmware can lose bytes, and to solve that we can reduce the size of the buffer. 	So I'm writing to ask the specific steps to reduce the buffer and recompile the firmware, and I've tried by myself but I couldn't find a proper toolchain which includes a GCC but not an EABI.	I'm looking forward to your reply. Best wishes!																			Yours, sincerely																			Luna-Qi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20161213/f85eb7bb/attachment.htm>

From ml at mail.tsaitgaist.info  Tue Dec 13 19:08:41 2016
From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info)
Date: Tue, 13 Dec 2016 20:08:41 +0100
Subject: Some Questions about Simtrace
In-Reply-To: <20161213132213.E902638053A@webmail.sinamail.sina.com.cn>
References: <20161213132213.E902638053A@webmail.sinamail.sina.com.cn>
Message-ID: <20161213190841.GA23671@coil.fritz.box>

AFAIR the wireshark dissector only knows about the SIM RUN GSM ALGORITHM APDU format (with Kc), but not the USIM AUTHENTICATE APDU format (with CK and IK).
https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-gsm_sim.c#L1618
This is why it should always return a malformed packet (due to the dissector decoder).
Did you check if the raw bytes actually match the USIM APDU and include CK+IK, or are bytes also missing there?

On Tue, Dec 13, 2016 at 09:22:13PM +0800, joranglequeen at sina.com wrote:
>  Dear Sir or Madam:	I've bought two simtrace development boards two months ago in order to research the communication between the SIM-card and the mobile phone. However, recently when I need to analyse the packet which contains CK and IK, I sadly found that the packet was not captured every time. Mostly it returns as a malformed packet in the wireshark, which blocks my future studying. I read the user manual and it says that for some high speed cards the firmware can lose bytes, and to solve that we can reduce the size of the buffer. 	So I'm writing to ask the specific steps to reduce the buffer and recompile the firmware, and I've tried by myself but I couldn't find a proper toolchain which includes a GCC but not an EABI.	I'm looking forward to your reply. Best wishes!																			Yours, sincerely																			Luna-Qi


From min.xu at min-info.net  Tue Dec 13 20:23:43 2016
From: min.xu at min-info.net (Min Xu)
Date: Tue, 13 Dec 2016 10:23:43 -1000
Subject: Basic questions (Michael Kramer)
Message-ID: <CADYTO8Qxhn9VrfYsHkyqk6f8Y0LH3ZWfp+DRMnYmuXizRaAbVw@mail.gmail.com>

>
>    1. Re: Basic questions (Michael Kramer)
>    2. Very basic questions (?? ???)
>    3. Re: Basic questions (J. F?lix Onta?on)
>    4. Re: Very basic questions (Holger Freyther)
>
>
> ---------- Forwarded message ----------
> From: Michael Kramer <michael.kramer at uni-konstanz.de>
> To: "J. F?lix Onta?on" <felix.ontanon at podsystem.com>
> Cc: simtrace at 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 at 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 at freyther.de>:
> > >
> > >
> > > > On 16 Oct 2016, at 22:15, Michael Kramer <
> michael.kramer at uni-konstanz.de>
> > wrote:
> > > >
> > > >
> > > > Am Freitag, 14. Oktober 2016 22:19 CEST, Holger Freyther <
> > holger at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20161213/14498b76/attachment.htm>

From min.xu at min-info.net  Tue Dec 13 20:29:14 2016
From: min.xu at min-info.net (Min Xu)
Date: Tue, 13 Dec 2016 10:29:14 -1000
Subject: Some Questions about Simtrace
Message-ID: <CADYTO8RyT==C_xRF+2M-rAMnLeAtkUzzrSuRPrS31od3LOzC3Q@mail.gmail.com>

Hi Luna

I am not sure why this question is still coming up.  I am under the
impression that git already includes my changes, which I believe already
resolves buffering issues.  I have no issues reading CK/IK commands
(although I do recommend you to use your own parser as I think wireshark
parser is very limited) on any 3G/4G sim cards.

You should be able to find a binary build of the changes I made in an
earlier email I submited.  However, do take note that the client
application will have to be changed as well because additional fields had
to be added to the usb packet header)

Best regards


On Tue, Dec 13, 2016 at 3:32 AM, <simtrace-request at lists.osmocom.org> wrote:

> ---------- Forwarded message ----------
> From: <joranglequeen at sina.com>
> To: simtrace <simtrace at lists.osmocom.org>
> Cc:
> Date: Tue, 13 Dec 2016 21:22:13 +0800
> Subject: Some Questions about Simtrace
>  Dear Sir or Madam:
> I've bought two simtrace development boards two months ago in order to
> research the communication between the SIM-card and the mobile phone.
> However, recently when I need to analyse the packet which contains CK and
> IK, I sadly found that the packet was not captured every time. Mostly it
> returns as a malformed packet in the wireshark, which blocks my future
> studying. I read the user manual and it says that for some high speed cards
> the firmware can lose bytes, and to solve that we can reduce the size of
> the buffer. So I'm writing to ask the specific steps to reduce the buffer
> and recompile the firmware, and I've tried by myself but I couldn't find a
> proper toolchain which includes a GCC but not an EABI.
> I'm looking forward to your reply. Best wishes!
> Yours, sincerely
> Luna-Qi
>
> _______________________________________________
> simtrace mailing list
> simtrace at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/simtrace
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20161213/2a29b528/attachment.htm>

From laforge at gnumonks.org  Tue Dec 13 23:12:52 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2016 00:12:52 +0100
Subject: Some Questions about Simtrace
In-Reply-To: <20161213190841.GA23671@coil.fritz.box>
References: <20161213132213.E902638053A@webmail.sinamail.sina.com.cn>
 <20161213190841.GA23671@coil.fritz.box>
Message-ID: <20161213231252.q2qrd6oxz53fktpx@nataraja>

Hi Kevin,

On Tue, Dec 13, 2016 at 08:08:41PM +0100, ml at mail.tsaitgaist.info wrote:
> AFAIR the wireshark dissector only knows about the SIM RUN GSM
> ALGORITHM APDU format (with Kc), but not the USIM AUTHENTICATE APDU
> format (with CK and IK).

yes, this is true. I can only re-iterate that Osmocom SIMtrace, just
like wreshark, are community-based collaborative Free Software
development projects, and they will always only support whatever
somebody decides to contribute in terms of code.

Every user would be more than happy if somebody implemented dissection
of USIM/UICC, or even dissection of the actual EF content [which is of
course different for each EF].

The existing GSM SIM dissector was the minimal posible useful set that I
could implement at the time.  Unfortuantely, nobody seems to have
followed up in all those years, except for Pascal Quentin with some much
appreciated SIM Toolkit related work.

So everyone at that list: Each time you see something missing, please
take some time to implement it.  Only that way collaborative software
development projects are stustainable.  Thanks for your understanding.

Kevin and I certainly did our part to get SIMtrace off the ground many
years ago in terms of hardware, firmware and the existing application
code / wiershark code.  If you're reading this: Now it's your turn,
pleaes help make the project better and more complete.  Thanks!

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)


From koksu at list.ru  Mon Dec 26 16:30:03 2016
From: koksu at list.ru (=?UTF-8?B?0K8=?=)
Date: Mon, 26 Dec 2016 16:30:03 -0000
Subject: =?UTF-8?B?c3BhbnNpb24gZmwwMzJwaWYg?=
Message-ID: <1482761210.587946964@f25.i.mail.ru>

Why in the circuit with simtrase used spansion fl032pif that is stored in it?


-- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20161226/6fc3e3b9/attachment.htm>