From laforge at gnumonks.org Tue Aug 2 10:22:39 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 2 Aug 2011 12:22:39 +0200 Subject: at91lib / multi-configuration device Message-ID: <20110802102238.GL18947@prithivi.gnumonks.org> Hi! It took me quite a long time to fix all the bugs I discovered in the at91lib USB stack, particularly in the CCID code. The next problem was that the core USB code could not deal wit devices that implement multiple configurations correctly. But finally I got it to work. There is now a multi-configuration project which is part of the git://git.gnumonks.org/at91work.git git repository. Curious people can type 'make' in the usb-device-multi-project sub-directory, which will render a usb-device-multi-project-simtrace-at91sam7s128-flash_dfu.bin file. That file can be flashed into the simtrace using dfu-util like this: dfu-util -a0 -D ./usb-device-multi-project-simtrace-at91sam7s128-flash_dfu.bin -R The firmware doesn't really do anything yet, but it should show up on USB as a device with three configurations (one for sniffer, one for reader and one for MITM). I've started to port over my sniffer code from the openpcd repository, but I'm not sure when I'll have time to finish it. Maybe still before the camp, we'll see... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Aug 4 12:13:12 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 4 Aug 2011 14:13:12 +0200 Subject: SIMtrace poster for the Camp? Message-ID: <20110804121312.GE15837@prithivi.gnumonks.org> Hi all! I know it's a bit on short hand notice now, but maybe somebody is interested in doing a SIMtrace poster that we can put up in the Radio Village at the CCC Camp. It doesn't have to be super-fancy / super-glossy, just something that draws a bit of attention that SIMtrace is present there, and what it is. Some ideas for bullet points: * trace communication between phone and SIM * man-in-the-middle * analyze + debug SIM Toolkit * analyze proactive SIM * SIM firewall * SIM card emulation Printing the poster shouldn't be a problem, if somebody just wants to do the design as SVG. Thanks in advance if anyone finds time for doing it... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kevredon at mail.tsaitgaist.info Thu Aug 4 22:46:14 2011 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Fri, 05 Aug 2011 00:46:14 +0200 Subject: SIMtrace poster for the Camp? In-Reply-To: <20110804121312.GE15837@prithivi.gnumonks.org> References: <20110804121312.GE15837@prithivi.gnumonks.org> Message-ID: <4E3B2136.8040203@mail.tsaitgaist.info> Hi, I'll try to do one in the next day, but I can't promise anything as I am quite busy. kevin On 04.08.2011 14:13, Harald Welte wrote: > > Thanks in advance if anyone finds time for doing it... > From spe at stacken.kth.se Fri Aug 12 12:32:20 2011 From: spe at stacken.kth.se (Stefan Petersen) Date: Fri, 12 Aug 2011 14:32:20 +0200 Subject: Connecting the FTDI cable Message-ID: <4E451D54.4050308@stacken.kth.se> Hello! I skimmed over the schematic and noticed that the power output from the FTDI cable is connected directly to the 3.3V line. In my experience the output from the FTDI cable is 5V even though it is the 3.3V version. I have actually fried some designs due to this. I'm not 100% sure about this, but my tips is to check it before you connect it. Best regards, /Stefan From lists at lukaperkov.net Fri Aug 12 14:08:21 2011 From: lists at lukaperkov.net (Luka Perkov) Date: Fri, 12 Aug 2011 16:08:21 +0200 Subject: [PATCH] fix simtrace crash when unpluging usb Message-ID: <20110812140820.GB12234@w500.camp.ccc.de> This patch should fix the crash from simtrace app when SIMtrace hardware is unpluged from usb or when it is reseted. This feature was proposed on simtrace workshop on ccc camp. Signed-off-by: Luka Perkov < lists ->-to->- lukaperkov.net > --- diff --git a/host/main.c b/host/main.c index a1e5600..61656be 100644 --- a/host/main.c +++ b/host/main.c @@ -187,7 +187,14 @@ int main(int argc, char **argv) rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000); if (rc < 0 && rc != -EAGAIN) { fprintf(stderr, "Error submitting BULK IN urb: %s\n", usb_strerror()); - exit(1); + while (1) { + udev = usb_find_reopen(SIMTRACE_USB_VENDOR, SIMTRACE_USB_PRODUCT); + if (!udev) { + usleep(1000000); + } else { + break; + } + } } if (rc > 0) { //printf("URB: %s\n", osmo_hexdump(buf, rc)); diff --git a/host/usb_helper.c b/host/usb_helper.c index 231363a..97ea7b6 100644 --- a/host/usb_helper.c +++ b/host/usb_helper.c @@ -28,6 +28,8 @@ #include +static struct usb_dev_handle *hdl; + static struct usb_device *find_usb_device (uint16_t vendor_id, uint16_t product_id) { struct usb_bus *bus; @@ -46,8 +48,6 @@ static struct usb_device *find_usb_device (uint16_t vendor_id, uint16_t product_ struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) { struct usb_device *dev; - struct usb_dev_handle *hdl; - usb_init(); usb_find_busses(); usb_find_devices(); @@ -56,7 +56,7 @@ struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) if (!dev) { fprintf(stderr, "Cannot find matching USB Device. " "Are you sure it is connected?\n"); - exit(1); + return NULL; } hdl = usb_open(dev); @@ -74,3 +74,12 @@ struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) return hdl; } + +struct usb_dev_handle *usb_find_reopen(uint16_t vendor_id, uint16_t product_id) +{ + if (hdl) { + usb_detach_kernel_driver_np(hdl, 0); + } + + return usb_find_open(vendor_id, product_id); +} diff --git a/host/usb_helper.h b/host/usb_helper.h index 13f96f8..0a9714c 100644 --- a/host/usb_helper.h +++ b/host/usb_helper.h @@ -22,5 +22,6 @@ #include struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id); +struct usb_dev_handle *usb_find_reopen(uint16_t vendor_id, uint16_t product_id); #endif From holger at freyther.de Sat Aug 13 09:53:17 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 13 Aug 2011 11:53:17 +0200 Subject: SIMtrace usermanual Message-ID: <4E46498D.1080102@freyther.de> Hi all, there is a doc/ directory in the simtrace source and the documentation is done with docbook. The result of the document can be seen here[1]. It is still missing proof reading, sections on building the patched wireshark, building the firmware and more content. comments welcome holger [1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/usermanual.pdf From laforge at gnumonks.org Sat Aug 13 18:02:22 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Aug 2011 20:02:22 +0200 Subject: Connecting the FTDI cable In-Reply-To: <4E451D54.4050308@stacken.kth.se> References: <4E451D54.4050308@stacken.kth.se> Message-ID: <20110813180222.GB26616@prithivi.gnumonks.org> On Fri, Aug 12, 2011 at 02:32:20PM +0200, Stefan Petersen wrote: > Hello! > > I skimmed over the schematic and noticed that the power output from the > FTDI cable is connected directly to the 3.3V line. In my experience the > output from the FTDI cable is 5V even though it is the 3.3V version. I > have actually fried some designs due to this. thanks a lot for pointing this out! I recommend cutting the voltage wire of the 6pin FTDI connector before plugging the cable into the simtrace. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sat Aug 13 19:15:02 2011 From: peter at stuge.se (Peter Stuge) Date: Sat, 13 Aug 2011 21:15:02 +0200 Subject: [PATCH 1/3] Include for malloc() and free() Message-ID: <1313262904-4182-1-git-send-email-peter@stuge.se> --- host/main.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/host/main.c b/host/main.c index a1e5600..1823857 100644 --- a/host/main.c +++ b/host/main.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include -- 1.7.4.1.343.ga91df.dirty From peter at stuge.se Sat Aug 13 19:15:03 2011 From: peter at stuge.se (Peter Stuge) Date: Sat, 13 Aug 2011 21:15:03 +0200 Subject: [PATCH 2/3] Silence warning: initialization from incompatible pointer type In-Reply-To: <1313262904-4182-1-git-send-email-peter@stuge.se> References: <1313262904-4182-1-git-send-email-peter@stuge.se> Message-ID: <1313262904-4182-2-git-send-email-peter@stuge.se> --- host/main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/host/main.c b/host/main.c index 1823857..8e63448 100644 --- a/host/main.c +++ b/host/main.c @@ -84,7 +84,7 @@ static void apdu_out_cb(uint8_t *buf, unsigned int len, void *user_data) static int process_usb_msg(uint8_t *buf, int len) { - struct simtrace_hdr *sh = buf; + struct simtrace_hdr *sh = (struct simtrace_hdr *)buf; uint8_t *payload = buf += sizeof(*sh); int payload_len = len - sizeof(*sh); -- 1.7.4.1.343.ga91df.dirty From peter at stuge.se Sat Aug 13 19:15:04 2011 From: peter at stuge.se (Peter Stuge) Date: Sat, 13 Aug 2011 21:15:04 +0200 Subject: [PATCH 3/3] Use libusb-1.0 for USB communication In-Reply-To: <1313262904-4182-1-git-send-email-peter@stuge.se> References: <1313262904-4182-1-git-send-email-peter@stuge.se> Message-ID: <1313262904-4182-3-git-send-email-peter@stuge.se> --- host/Makefile | 6 ++-- host/main.c | 55 +++++++++++++++++++++++---------- host/usb.c | 87 ----------------------------------------------------- host/usb_helper.c | 76 ---------------------------------------------- host/usb_helper.h | 26 ---------------- 5 files changed, 41 insertions(+), 209 deletions(-) delete mode 100644 host/usb.c delete mode 100644 host/usb_helper.c delete mode 100644 host/usb_helper.h diff --git a/host/Makefile b/host/Makefile index 03120c4..247cabc 100644 --- a/host/Makefile +++ b/host/Makefile @@ -1,12 +1,12 @@ -LDFLAGS=-lusb `pkg-config --libs libosmocore` -losmocore +LDFLAGS=`pkg-config --libs libusb-1.0` `pkg-config --libs libosmocore` -losmocore all: simtrace -simtrace: main.o usb_helper.o usb.o apdu_split.o +simtrace: main.o apdu_split.o $(CC) -o $@ $^ $(LDFLAGS) %.o: %.c - $(CC) $(CFLAGS) `pkg-config --cflags libosmocore` -o $@ -c $^ + $(CC) $(CFLAGS) `pkg-config --cflags libusb-1.0` `pkg-config --cflags libosmocore` -o $@ -c $^ install: simtrace install -d $(DESTDIR)/usr/bin/ diff --git a/host/main.c b/host/main.c index 8e63448..4fbac8d 100644 --- a/host/main.c +++ b/host/main.c @@ -32,9 +32,8 @@ #include #include -#include +#include -#include "usb_helper.h" #include "simtrace.h" #include "simtrace_usb.h" #include "apdu_split.h" @@ -43,7 +42,7 @@ #include #include -static struct usb_dev_handle *udev; +static struct libusb_device_handle *devh; static struct apdu_split *as; static struct gsmtap_inst *g_gti; @@ -140,8 +139,9 @@ int main(int argc, char **argv) { char buf[16*265]; char *gsmtap_host = "127.0.0.1"; - int rc, c; + int rc, c, ret = 1; int skip_atr = 0; + int xfer_len; unsigned int msg_count, byte_count = 0; print_welcome(); @@ -166,35 +166,56 @@ int main(int argc, char **argv) } } + rc = libusb_init(NULL); + if (rc < 0) { + fprintf(stderr, "libusb initialization failed\n"); + goto close_exit; + } + g_gti = gsmtap_source_init(gsmtap_host, GSMTAP_UDP_PORT, 0); if (!g_gti) { perror("unable to open GSMTAP"); - exit(1); + goto close_exit; } gsmtap_source_add_sink(g_gti); - udev = usb_find_open(SIMTRACE_USB_VENDOR, SIMTRACE_USB_PRODUCT); - if (!udev) { - perror("opening USB device"); - exit(1); + devh = libusb_open_device_with_vid_pid(NULL, SIMTRACE_USB_VENDOR, SIMTRACE_USB_PRODUCT); + if (!devh) { + fprintf(stderr, "can't open USB device\n"); + goto close_exit; + } + + rc = libusb_claim_interface(devh, 0); + if (rc < 0) { + fprintf(stderr, "can't claim interface; rc=%d\n", rc); + goto close_exit; } as = apdu_split_init(&apdu_out_cb, NULL); if (!as) - exit(1); + goto release_exit; printf("Entering main loop\n"); while (1) { - rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000); - if (rc < 0 && rc != -EAGAIN) { - fprintf(stderr, "Error submitting BULK IN urb: %s\n", usb_strerror()); - exit(1); + rc = libusb_bulk_transfer(devh, SIMTRACE_IN_EP, buf, sizeof(buf), &xfer_len, 100000); + if (rc < 0 && rc != LIBUSB_ERROR_TIMEOUT) { + fprintf(stderr, "BULK IN transfer error; rc=%d\n", rc); + goto release_exit; } - if (rc > 0) { + if (xfer_len > 0) { //printf("URB: %s\n", osmo_hexdump(buf, rc)); - process_usb_msg(buf, rc); + process_usb_msg(buf, xfer_len); msg_count++; - byte_count += rc; + byte_count += xfer_len; } } + ret = 0; + +release_exit: + libusb_release_interface(devh, 0); +close_exit: + if (devh) + libusb_close(devh); + libusb_exit(NULL); + return ret; } diff --git a/host/usb.c b/host/usb.c deleted file mode 100644 index 1d3aaf4..0000000 --- a/host/usb.c +++ /dev/null @@ -1,87 +0,0 @@ -#include -#include -#include -#include -#include -#include -#include "usb.h" -#include - -#define MAX_READ_WRITE 4096 - -#define USB_ERROR_STR(ret, x, args...) return ret - -static int usb_get_fd(usb_dev_handle *uh) -{ - return *((int *)uh); -} - -int __usb_bulk_write(usb_dev_handle *dev, int ep, char *bytes, int length, - int timeout) -{ - struct usbdevfs_bulktransfer bulk; - int ret, sent = 0; - - /* Ensure the endpoint address is correct */ - ep &= ~USB_ENDPOINT_IN; - - do { - bulk.ep = ep; - bulk.len = length - sent; - if (bulk.len > MAX_READ_WRITE) - bulk.len = MAX_READ_WRITE; - bulk.timeout = timeout; - bulk.data = (unsigned char *)bytes + sent; - - ret = ioctl(usb_get_fd(dev), USBDEVFS_BULK, &bulk); - if (ret < 0) - USB_ERROR_STR(ret, - "error writing to bulk endpoint %d: %s", - ep, strerror(errno)); - - sent += ret; - } while (ret > 0 && sent < length); - - return sent; -} - -int __usb_bulk_read(usb_dev_handle *dev, int ep, char *bytes, int size, - int timeout) -{ - struct usbdevfs_bulktransfer bulk; - int ret, retrieved = 0, requested; - - /* Ensure the endpoint address is correct */ - ep |= USB_ENDPOINT_IN; - - do { - bulk.ep = ep; - requested = size - retrieved; - if (requested > MAX_READ_WRITE) - requested = MAX_READ_WRITE; - bulk.len = requested; - bulk.timeout = timeout; - bulk.data = (unsigned char *)bytes + retrieved; - - ret = ioctl(usb_get_fd(dev), USBDEVFS_BULK, &bulk); - if (ret < 0) - USB_ERROR_STR(ret, - "error reading from bulk endpoint 0x%x: %s", - ep, strerror(errno)); - - retrieved += ret; - } while (ret > 0 && retrieved < size && ret == requested); - - return retrieved; -} - -int __usb_reattach_kernel_driver_np(usb_dev_handle *dev, int interface) -{ - struct usbdevfs_ioctl command; - - command.ifno = interface; - command.ioctl_code = USBDEVFS_CONNECT; - command.data = NULL; - - return ioctl(usb_get_fd(dev), USBDEVFS_IOCTL, &command); -} diff --git a/host/usb_helper.c b/host/usb_helper.c deleted file mode 100644 index 231363a..0000000 --- a/host/usb_helper.c +++ /dev/null @@ -1,76 +0,0 @@ -/* usb_helper - Low-Level USB routines for SimTrace - * - * (C) 2006-2010 by Harald Welte - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 - * as published by the Free Software Foundation - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ - -#include -#include -#include -#include -#include -#include -#include - -#include - -#include - -static struct usb_device *find_usb_device (uint16_t vendor_id, uint16_t product_id) -{ - struct usb_bus *bus; - - for (bus = usb_busses; bus; bus = bus->next) { - struct usb_device *dev; - for (dev = bus->devices; dev; dev = dev->next) { - if (dev->descriptor.idVendor == vendor_id && - dev->descriptor.idProduct == product_id) - return dev; - } - } - return NULL; -} - -struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) -{ - struct usb_device *dev; - struct usb_dev_handle *hdl; - - usb_init(); - usb_find_busses(); - usb_find_devices(); - - dev = find_usb_device(vendor_id, product_id); - if (!dev) { - fprintf(stderr, "Cannot find matching USB Device. " - "Are you sure it is connected?\n"); - exit(1); - } - - hdl = usb_open(dev); - if (!hdl) { - fprintf(stderr, "Unable to open usb device: %s\n", - usb_strerror()); - exit(1); - } - - if (usb_claim_interface(hdl, 0) < 0) { - fprintf(stderr, "Unable to claim usb interface " - "1 of device: %s\n", usb_strerror()); - exit(1); - } - - return hdl; -} diff --git a/host/usb_helper.h b/host/usb_helper.h deleted file mode 100644 index 13f96f8..0000000 --- a/host/usb_helper.h +++ /dev/null @@ -1,26 +0,0 @@ -#ifndef _USB_HELPER_H -#define _USB_HELPER_H - -/* usb_helper - Low-Level USB routines for SimTrace - * - * (C) 2006-2010 by Harald Welte - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 - * as published by the Free Software Foundation - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ - -#include - -struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id); - -#endif -- 1.7.4.1.343.ga91df.dirty From holger at freyther.de Sun Aug 14 13:11:18 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 14 Aug 2011 15:11:18 +0200 Subject: tags for the hardware Message-ID: <4E47C976.2020500@freyther.de> Hi all, are there tags for the v1.0p hardware and other prototypes? I don't see them with git tag -l. holger From laforge at gnumonks.org Mon Aug 15 08:32:28 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 Aug 2011 10:32:28 +0200 Subject: [PATCH 1/3] Include for malloc() and free() In-Reply-To: <1313262904-4182-1-git-send-email-peter@stuge.se> References: <1313262904-4182-1-git-send-email-peter@stuge.se> Message-ID: <20110815083228.GK27344@prithivi.gnumonks.org> Thanks Peter, I've merged all 3 patches. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Aug 15 08:30:53 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 Aug 2011 10:30:53 +0200 Subject: tags for the hardware In-Reply-To: <4E47C976.2020500@freyther.de> References: <4E47C976.2020500@freyther.de> Message-ID: <20110815083053.GJ27344@prithivi.gnumonks.org> On Sun, Aug 14, 2011 at 03:11:18PM +0200, Holger Hans Peter Freyther wrote: > Hi all, > > are there tags for the v1.0p hardware and other prototypes? I don't see them > with git tag -l. there are no tags, there's just the 'v1.0production' branch which contains the production release. previous prototypes do neither have branches nor tags so far. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Aug 15 09:38:58 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Aug 2011 11:38:58 +0200 Subject: Connecting the FTDI cable In-Reply-To: <20110813180222.GB26616@prithivi.gnumonks.org> References: <4E451D54.4050308@stacken.kth.se> <20110813180222.GB26616@prithivi.gnumonks.org> Message-ID: <4E48E932.5020603@freyther.de> On 08/13/2011 08:02 PM, Harald Welte wrote: > I recommend cutting the voltage wire of the 6pin FTDI connector before > plugging the cable into the simtrace. added the information to the wiki and usermanual: http://bb.osmocom.org/trac/wiki/SIMtrace/Hardware?version=10 http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/usermanual.pdf z. From holger at freyther.de Mon Aug 15 09:40:22 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Aug 2011 11:40:22 +0200 Subject: SIMtrace usermanual In-Reply-To: <4E46498D.1080102@freyther.de> References: <4E46498D.1080102@freyther.de> Message-ID: <4E48E986.5020507@freyther.de> On 08/13/2011 11:53 AM, Holger Hans Peter Freyther wrote: > Hi all, Hi again, Kevin pointed me to the SIMtrace/Hardware article, I have included the surface picture and added callouts with docbook. The new version of the manual can be found at the same link. > > [1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/usermanual.pdf > From holger at freyther.de Mon Aug 15 13:16:56 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Aug 2011 15:16:56 +0200 Subject: TST PIN and SIMtrace Schematic question Message-ID: <4E491C48.2050208@freyther.de> Hi all, I have a stupid schematic question. I read section 6.2 of the SAM7 datasheet (as in the git tree) and it mentions that besides TST high also PA0, PA1 and PA2 needs to be high, and PA0, PA1 should not be low as this leads to unpredictable results. So I wonder about the following: - PA0 is not connected, default state should be high - PA1 is connected with a trace that leads to PA6 - PA2 is connected with a trace that leads to PA4 will PA4, PA6 work like a pull down (I am not sure of Table 10-3)? cheers holger From kevredon at mail.tsaitgaist.info Mon Aug 15 13:38:25 2011 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 15 Aug 2011 15:38:25 +0200 Subject: Connecting the FTDI cable In-Reply-To: <4E48E932.5020603@freyther.de> References: <4E451D54.4050308@stacken.kth.se> <20110813180222.GB26616@prithivi.gnumonks.org> <4E48E932.5020603@freyther.de> Message-ID: <4E492151.9020804@mail.tsaitgaist.info> Hi, On 15.08.2011 11:38, Holger Hans Peter Freyther wrote: > On 08/13/2011 08:02 PM, Harald Welte wrote: >> I recommend cutting the voltage wire of the 6pin FTDI connector before >> plugging the cable into the simtrace. > This pin will not be connected in v1.1. I will also write a ticket for it. Thanks for the warning. Kevin From laforge at gnumonks.org Mon Aug 15 16:30:54 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 Aug 2011 18:30:54 +0200 Subject: TST PIN and SIMtrace Schematic question In-Reply-To: <4E491C48.2050208@freyther.de> References: <4E491C48.2050208@freyther.de> Message-ID: <20110815163054.GH6706@prithivi.gnumonks.org> Hi Holger, On Mon, Aug 15, 2011 at 03:16:56PM +0200, Holger Hans Peter Freyther wrote: > I have a stupid schematic question. I read section 6.2 of the SAM7 datasheet > (as in the git tree) and it mentions that besides TST high also > PA0, PA1 and PA2 needs to be high, and PA0, PA1 should not be low as this > leads to unpredictable results. Yes, this is correct. > So I wonder about the following: > - PA0 is not connected, default state should be high > - PA1 is connected with a trace that leads to PA6 > - PA2 is connected with a trace that leads to PA4 > > will PA4, PA6 work like a pull down (I am not sure of Table 10-3)? All GPIO of the SAM7 have internal pull-up resistors which are enabled at boot. Thus, they should all be in high state. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Aug 15 19:04:35 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Aug 2011 21:04:35 +0200 Subject: TST PIN and SIMtrace Schematic question In-Reply-To: <20110815163054.GH6706@prithivi.gnumonks.org> References: <4E491C48.2050208@freyther.de> <20110815163054.GH6706@prithivi.gnumonks.org> Message-ID: <4E496DC3.1070404@freyther.de> On 08/15/2011 06:30 PM, Harald Welte wrote: > Hi Holger, >> >> will PA4, PA6 work like a pull down (I am not sure of Table 10-3)? > > All GPIO of the SAM7 have internal pull-up resistors which are enabled > at boot. Thus, they should all be in high state. > Ah, it would have been too easy, Page 6 of the SAM7 datasheet confirms that: " Pulled-up input at reset PA0 - PA20 only on AT91SAM7S32/16 " cheers holger From laforge at gnumonks.org Mon Aug 15 21:06:40 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 Aug 2011 23:06:40 +0200 Subject: 'no simcard' bug / SIMtrace firmware update Message-ID: <20110815210640.GH11707@prithivi.gnumonks.org> Hi all, I have meanwhile solved the first half of the bug that was causing a lot of problems during the CCC Camp 2011. In git commit fa7297b93f4187bce9439bb676874815f66d8f21 to openpcd.git, I have made the following changes: * make sure SIMtrace remains completely passive even in case of (alleged) parity errors * prevent an IRQ storm by properly clearing error flags in the USART, which have lead to a watchdog triggered reset which in turn caused a USB disconnect So right now, you should not see the "No SIM card" or "SIM card error" in the display of your phone, no matter what phone / simcard is used. However, the data logged by SIMtrace still is incorrect in those cases. I hope to release a fix for that soon. The updated 'main_simtrace.bin' firmware is attached to this mail. You can install it by using "dfu-util -d 16c0:0762 -a0 -D ./main_simtrace.bin -R" which should produce something like: ======= dfu-util - (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util does currently only support DFU version 1.0 Opening USB Device 0x16c0:0x0762... Claiming USB DFU Runtime Interface... Determining device status: state = appIDLE, status = 0 Device really in Runtime Mode, send DFU detach request... Resetting USB... Opening USB Device... Found Runtime: [0x16c0:0x0762] devnum=41, cfg=0, intf=0, alt=0, name="SimTrace DFU Interface - Application Partition" Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Device returned transfer size 256 bytes_per_hash=415 Copying data from PC to DFU device Starting download: [##################################################] finished! state(7) = dfuMANIFEST, status(0) = No error condition is present state(2) = dfuIDLE, status(0) = No error condition is present Done! can't detach: error sending control message: Broken pipe Resetting USB to switch back to runtime mode ======== After that, the new firmware has been programmed into your SIMtrace and you can immediately use it again (no reset/re-plug/... needed) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: main_simtrace.bin Type: application/octet-stream Size: 20756 bytes Desc: not available URL: From laforge at gnumonks.org Tue Aug 16 08:26:37 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 Aug 2011 10:26:37 +0200 Subject: [SOLVED] 'no simcard' bug / SIMtrace firmware update In-Reply-To: <20110815210640.GH11707@prithivi.gnumonks.org> References: <20110815210640.GH11707@prithivi.gnumonks.org> Message-ID: <20110816082637.GA23483@prithivi.gnumonks.org> Hi all, On Mon, Aug 15, 2011 at 11:06:40PM +0200, Harald Welte wrote: > However, the data logged by SIMtrace still is incorrect in those cases. > I hope to release a fix for that soon. some more investigation results in the following observation: Some ATR seem to be without the final TCK (checksum) byte. So far I thought, that the TCK is always present. As it seems, ISO 7816-3 indicates that TCK is _not_ present if a card only supports the T=0 protocol. So SIMtrace was working for all cards that e.g. support T=0 and T=1, but failed for those that only do T=0 like our 16in1 SIM cards used on 27C3 and the CCC Camp 2011. I've again attached an updated firmware image. Please follow the dfu-util instructions from my last message to install it in your SIMtrace device. I'd appreciate if this new firmware solves the commonly-observed bug resulting in USB disconnect and the "No SIM card" error observed in some phones. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: main_simtrace-v0.2.bin Type: application/octet-stream Size: 20844 bytes Desc: not available URL: From spe at stacken.kth.se Tue Aug 16 09:18:49 2011 From: spe at stacken.kth.se (Stefan Petersen) Date: Tue, 16 Aug 2011 11:18:49 +0200 Subject: [SOLVED] 'no simcard' bug / SIMtrace firmware update In-Reply-To: <20110816082637.GA23483@prithivi.gnumonks.org> References: <20110815210640.GH11707@prithivi.gnumonks.org> <20110816082637.GA23483@prithivi.gnumonks.org> Message-ID: <4E4A35F9.6050500@stacken.kth.se> On 08/16/2011 10:26 AM, Harald Welte wrote: > Hi all, [snip] > I'd appreciate if this new firmware solves the commonly-observed bug > resulting in USB disconnect and the "No SIM card" error observed in some > phones. Both phones I have here are now running without any crashes. Swedish 3G-operator Tre in an HTC and a SE W810i with CCC-sim (the last one complains about no network coverage, well well ;) ) No analysis yet. Good work, Harald. /Stefan From kevredon at mail.tsaitgaist.info Thu Aug 18 20:24:17 2011 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Thu, 18 Aug 2011 22:24:17 +0200 Subject: samba precondition Message-ID: <4E4D74F1.3040401@mail.tsaitgaist.info> Hi, I think I found a small hardware bug while fixing the v1.0p boards (adding a 100nF capacitor near the LDO pin 4). When I want to put the SAM7S in SAM-BA mode (shorting TEST and 3.3V pins), it does not work, even after waiting a lot of time. The 2 LEDs are on, and when I touch PA0 (pin 48 on the right upper corner of the SAM7S, near the "A") with a piece of metal, the LEDs switch off and putting into SAM-BA mode works. maybe PA0 needs to be low/up but it is not connected and probably floating. The solution is easy, but should we correct that for the next version (if it is a real bug)? Also, simtrace seems to load sam_ba module, which I have to remove so I can use sam7util multiple times: sudo rmmod cdc_acm && sudo rmmod sam_ba && sudo ./sam7 --exec set_clock --exec unlock_regions --exec "flash ../openpcd/firmware/main_simtrace.samba" thanks, kevin From holger at freyther.de Thu Aug 18 21:17:14 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 18 Aug 2011 23:17:14 +0200 Subject: samba precondition In-Reply-To: <4E4D74F1.3040401@mail.tsaitgaist.info> References: <4E4D74F1.3040401@mail.tsaitgaist.info> Message-ID: <4E4D815A.3060404@freyther.de> On 08/18/2011 10:24 PM, Kevin Redon wrote: > Hi, > > I think I found a small hardware bug while fixing the v1.0p boards > (adding a 100nF capacitor near the LDO pin 4). > When I want to put the SAM7S in SAM-BA mode (shorting TEST and 3.3V > pins), it does not work, even after waiting a lot of time. > The 2 LEDs are on, and when I touch PA0 (pin 48 on the right upper > corner of the SAM7S, near the "A") with a piece of metal, the LEDs > switch off and putting into SAM-BA mode works. > maybe PA0 needs to be low/up but it is not connected and probably floating. > The solution is easy, but should we correct that for the next version > (if it is a real bug)? Interesting, I asked questions about the default state of PA0,PA1 and PA2 in the 'TST PIN and...'. So the SAM7 datasheet in the git repo says that: PA0-PA... default is: 'Pulled-up input at reset'. Sorry, I am a noob with HW but even with PA0 not connected... it should be pulled up and be a logical one? Did you check if there is a more recent version of the datasheet? From kevredon at mail.tsaitgaist.info Thu Aug 18 23:35:34 2011 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Fri, 19 Aug 2011 01:35:34 +0200 Subject: samba precondition In-Reply-To: <4E4D815A.3060404@freyther.de> References: <4E4D74F1.3040401@mail.tsaitgaist.info> <4E4D815A.3060404@freyther.de> Message-ID: <4E4DA1C6.2030509@mail.tsaitgaist.info> On 18.08.2011 23:17, Holger Hans Peter Freyther wrote: > Interesting, I asked questions about the default state of PA0,PA1 and PA2 in > the 'TST PIN and...'. So the SAM7 datasheet in the git repo says that: > > PA0-PA... default is: 'Pulled-up input at reset'. Sorry, I am a noob with HW > but even with PA0 not connected... it should be pulled up and be a logical > one? Did you check if there is a more recent version of the datasheet? I also though about it and the previous post. But I also saw PA0 needs to be high for SAM-BA, and the the pull-up is enabled at reset. That is why I was wondering. Also we had no problem with the devboard from olimex (with no additional pull-up). Maybe I'm doing something wrong. There is a newer version of the datasheet (28-Jul-11), but the information about that did not change. Thanks, Kevin From 246tnt at gmail.com Fri Aug 19 07:04:17 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 19 Aug 2011 09:04:17 +0200 Subject: samba precondition In-Reply-To: <4E4DA1C6.2030509@mail.tsaitgaist.info> References: <4E4D74F1.3040401@mail.tsaitgaist.info> <4E4D815A.3060404@freyther.de> <4E4DA1C6.2030509@mail.tsaitgaist.info> Message-ID: Hi, > There is a newer version of the datasheet (28-Jul-11), but the > information about that did not change. I also checked the errata sheet for the AT91SAM128 and didn't see anything relevant. Maybe we should check if a pullup on PA0 fixes the other board that had troube with SAM-BA, and if it's the case, just add it ... better be safe than sorry IMHO. (even if it's troubling not understanding _why_ ...) Cheers, Sylvain From laforge at gnumonks.org Thu Aug 18 23:56:57 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 19 Aug 2011 01:56:57 +0200 Subject: samba precondition In-Reply-To: <4E4D74F1.3040401@mail.tsaitgaist.info> References: <4E4D74F1.3040401@mail.tsaitgaist.info> Message-ID: <20110818235657.GC29093@prithivi.gnumonks.org> Hi Kevin, On Thu, Aug 18, 2011 at 10:24:17PM +0200, Kevin Redon wrote: > maybe PA0 needs to be low/up but it is not connected and probably floating. > The solution is easy, but should we correct that for the next version > (if it is a real bug)? As Holger already indicated, the data sheet claims very clearly that PA0 has an internal pull-up which is active at boot time. So the question is whether this is really the bug that we're seeing with activating SAM-BA using the 'normal' squence. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spe at stacken.kth.se Fri Aug 19 09:48:25 2011 From: spe at stacken.kth.se (Stefan Petersen) Date: Fri, 19 Aug 2011 11:48:25 +0200 Subject: samba precondition In-Reply-To: References: <4E4D74F1.3040401@mail.tsaitgaist.info> <4E4D815A.3060404@freyther.de> <4E4DA1C6.2030509@mail.tsaitgaist.info> Message-ID: <4E4E3169.7000403@stacken.kth.se> On 08/19/2011 09:04 AM, Sylvain Munaut wrote: > Hi, [snip] > Maybe we should check if a pullup on PA0 fixes the other board that > had troube with SAM-BA, and if it's the case, just add it ... better > be safe than sorry IMHO. (even if it's troubling not understanding > _why_ ...) Hello! First of all, I agree with Sylvain, better be safe than sorry. If you are reworking the boards anyhow, add resistors from PA0-PA3 to 3.3V (100k?). Also add a resistor from ground to the TEST pin (also maybe 100k?). If it doesn't help or screw things up, just don't mount them. In my designs I usually add a No Mount resistor to every not used pin of the MCU. Easier to patch in a wire if you screw up and floating pins makes me nervous. I am a big fan of 0 ohm and Not Mount resistors. I have previous experience with SAM7 and SAM-BA, a board for a customer that has been produced in 3 batches of 15 boards each. First step is to load SAM-BA onto the board. The sequence I have found working was: 1) Press and hold TEST 2) Generate a reset, by pressing and releasing the reset button. 3) Keep TEST pressed at about 20 seconds. If you feed power from an external supply you can see a change in current consumption when SAM-BA is done. Atmel says 10 seconds, but I think it is more. I then use serial download with Atmels own SAM-BA program (yes Windows in a VirtualBox). In the latest production batch (<6 months ago) of my boards there was a new version of the SAM7S with a C tucked on in the end (if I remember correctly). When I tried to download a program it said it was OK, but then the program was never written into the flash. After a long investigation I realized that it required a patch from Atmel for their SAM-BA program. That patch was not available from any website by then, but when I asked their support why it did not work they sent me the patch with an explanation. I can post it here if anyone is interested. We have also had problems with too small (physical outline) crystals, since they seems to have a too long startup time for SAM-BA. Should not be a problem here though. OK that was long, sorry. But my maybe there is a crumble in there that might solve your problem or gives you an epiphany. Best regards, /Stefan From dirk.kirsten at uni-konstanz.de Fri Aug 19 10:21:29 2011 From: dirk.kirsten at uni-konstanz.de (Dirk Kirsten) Date: Fri, 19 Aug 2011 12:21:29 +0200 Subject: availability through web shop? Message-ID: Hi, I just wanted to ask for a short heads up of the release schedule. I know you have been selling the boards at the CCC camp, but I haven't been there. It was mentioned on the list that you are planning to sell it through a web shop in the "2nd half of august". I am sorry for being in such a hurry, but I'd really like to have the boards on my desk in august, due to my holidays afterwards. Cheers, Dirk From holger at freyther.de Fri Aug 19 13:51:16 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 19 Aug 2011 15:51:16 +0200 Subject: availability through web shop? In-Reply-To: References: Message-ID: <4E4E6A54.2040307@freyther.de> On 08/19/2011 12:21 PM, Dirk Kirsten wrote: > Hi, > > I just wanted to ask for a short heads up of the release schedule. I know you > have been selling the boards at the CCC camp, but I haven't been there. It was > mentioned on the list that you are planning to sell it through a web shop in > the "2nd half of august". Hi, I have looked at various options. Most of the stores are either 'OpenCore', PHP or both. Then I found spreecommerce (ruby, consulting business model) and it looks very promising, but it is US centric in some ways. For payment we will start with PayPal Express Checkout (allows you to use PayPal, VISA, or local things like bank transfer..). So the issues I have are: - Apply VAT even on the initial checkout phase - Allow to specify EUVAT id and validate it - Enter data (e.g. shipping costs) - Take merge requests from github to fix rounding errors in paypal extension Alternatively: - I will create a stupid form and use that as shop.. regarding the timeframe, I will work on this Sunday/Monday and will hopefully resolve most issues or go for the webform. holger From 246tnt at gmail.com Fri Aug 19 13:53:51 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 19 Aug 2011 15:53:51 +0200 Subject: availability through web shop? In-Reply-To: <4E4E6A54.2040307@freyther.de> References: <4E4E6A54.2040307@freyther.de> Message-ID: Hi, Is there even boards left to sell ? I tought the first batch was sold out at CCC camp. Since I guess the second batch will wait for Kevin's second revision, that probably won't be manufactured before a couple of weeks ? Cheers, Sylvain From holger at freyther.de Fri Aug 19 13:57:03 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 19 Aug 2011 15:57:03 +0200 Subject: availability through web shop? In-Reply-To: References: <4E4E6A54.2040307@freyther.de> Message-ID: <4E4E6BAF.4060205@freyther.de> On 08/19/2011 03:53 PM, Sylvain Munaut wrote: > Hi, > > Is there even boards left to sell ? I tought the first batch was sold > out at CCC camp. > > Since I guess the second batch will wait for Kevin's second revision, > that probably won't be manufactured before a couple of weeks ? Hi, we have produced 100 boards, Harald/Kevin reworked about ~60 for the camp, Kevin is reworking the remaining ones, I don't know how many are defective (I assume not too many). holger From kevredon at mail.tsaitgaist.info Fri Aug 19 14:18:36 2011 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Fri, 19 Aug 2011 16:18:36 +0200 Subject: availability through web shop? In-Reply-To: <4E4E6BAF.4060205@freyther.de> References: <4E4E6A54.2040307@freyther.de> <4E4E6BAF.4060205@freyther.de> Message-ID: <4E4E70BC.2030306@mail.tsaitgaist.info> Hi I already fixed 10 yesterday. I flashed them (SAM-BA) with recent git, but I did no test them yet. I hope they will all be ready on Monday for shipping to Holger. kevin On 19.08.2011 15:57, Holger Hans Peter Freyther wrote: > On 08/19/2011 03:53 PM, Sylvain Munaut wrote: >> Hi, >> >> Since I guess the second batch will wait for Kevin's second revision, >> that probably won't be manufactured before a couple of weeks ? > From holger at freyther.de Sat Aug 27 22:24:50 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 28 Aug 2011 00:24:50 +0200 Subject: Webshop for the SIMtrace hardware Message-ID: <4E596EB2.8000406@freyther.de> Hi all, I have toyed with spreecommerce[1] on and off and would like to have some friendly users to see if the whole checkout process is working. The shop can be found here[2] but I would like to share some technical details with you. My patched spreecommerce can be found on gitorious[3], for some of the changes I should have created an extension but right now I think I prefer git pull --rebase to see what changed. If you enter your EUVAT number you should not be charged VAT (unless you are in Germany). We are using a CA Cert signed certificate, your browser will tell you that it is dangerous, I think we prefer putting the money into future HW products than getting a signature from a 'trust worthy' org. Shipping cost calculation is a bit of a mess, does anyone know if DHL offers an API for it? The installation has four zones (Germany, EUVAT region, USA, World Wide)? Terms/Conditions and Privacy Policy are very basic and need to be refined, with best effort I tried to make short and clear. Technical feedback, specially on caching, rails (security), etc. is very welcome. holger [1] spreecommerce.com [2] https://shop.sysmocom.de [3] https://gitorious.org/sysmocom-spreecommerce From laforge at gnumonks.org Mon Aug 29 08:40:29 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Aug 2011 10:40:29 +0200 Subject: Any progress reports / experience with SIMtrace? Message-ID: <20110829084029.GL23789@prithivi.gnumonks.org> Hi all, it's now something like two weeks after the first 60 or so SIMtrace kits have been sold - but remarkably quite in here. I've been busy with mostly non-technical stuff, so I couldn't spend any more time improving the firmware/software. However, at least some of the SIMtrace owners should have used the device until now and gathered some data and/or experience. Please feel free to share your progress or problems here, including topics like * firmware update * simtrace host software * wireshark dissector Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Aug 29 10:33:12 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Aug 2011 12:33:12 +0200 Subject: OT: Chinese C118 supply? Message-ID: <20110829103312.GN23789@prithivi.gnumonks.org> Hi all, at the CCC Camp two weeks ago, a Chinese guy approached me, stating that there he has contacts to a considerable supply of very inexpensive C1xx family phones in China. Unfortunately we didn't exchange contact details, so I'm trying this route. If you are the person that has talked to me about this topic, pleaes contact me by private e-mail. I would love to use this opportunity to provide inexpensive C1xx phones to the larger OsmocomBB user community. Thanks in advance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Mon Aug 29 13:19:28 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 29 Aug 2011 15:19:28 +0200 Subject: Any progress reports / experience with SIMtrace? In-Reply-To: <20110829084029.GL23789@prithivi.gnumonks.org> References: <20110829084029.GL23789@prithivi.gnumonks.org> Message-ID: Hi, I haven't used it much except for testing and playing a bit. Since the fw update, no issues. I didn't have any particular application in mind, just a handy tool to have directly in case I ever need it. > ?* firmware update Worked fine with exactly the command you posted. > ?* simtrace host software Since the fw update didn't have any problems with it, it sends data to wireshark just fine. Is it supposed to do more than that ? > ?* wireshark dissector It's a bit of a pain to apply the various patches needed for the various osmocom stuff (bb / openbsc / simtrace), but it works fine if you take 10-15 min to fix the conflicts / upstream changes by hand. Cheers, Sylvain From lukash at backstep.net Mon Aug 29 17:29:58 2011 From: lukash at backstep.net (Lukas Kuzmiak) Date: Mon, 29 Aug 2011 19:29:58 +0200 Subject: Any progress reports / experience with SIMtrace? In-Reply-To: References: <20110829084029.GL23789@prithivi.gnumonks.org> Message-ID: Hey, I use simtrace quite often lately and I haven't experienced any problems so far. It works fine with the phones I've been using for testing: Motorola C123 (mostly) Nokia E51 and couple other old nokia phones I haven't patched my wireshark as the patch didn't work with latest svn revision and I didn't really have time to patch the patch :) I know there were questions at CCC which version was patch meant to be used with, are there any news to this? or updates to the patch? I've been using the text output only so far with my own interpreter coded just as a shellscript and it seems sufficient for my usage currently. But for "the masses" it would be nice to have it included in wireshark trunk, I can participate with some more interpretations, I'll compare what I have and what's in the patch. Lukas On Mon, Aug 29, 2011 at 3:19 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > I haven't used it much except for testing and playing a bit. Since the > fw update, no issues. I didn't have any particular application in > mind, just a handy tool to have directly in case I ever need it. > > > > * firmware update > > Worked fine with exactly the command you posted. > > > > * simtrace host software > > Since the fw update didn't have any problems with it, it sends data to > wireshark just fine. Is it supposed to do more than that ? > > > > * wireshark dissector > > It's a bit of a pain to apply the various patches needed for the > various osmocom stuff (bb / openbsc / simtrace), but it works fine if > you take 10-15 min to fix the conflicts / upstream changes by hand. > > > Cheers, > > Sylvain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Aug 29 20:06:12 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Aug 2011 22:06:12 +0200 Subject: Any progress reports / experience with SIMtrace? In-Reply-To: References: <20110829084029.GL23789@prithivi.gnumonks.org> Message-ID: <20110829200612.GA822@prithivi.gnumonks.org> Hi Lukas, thanks for your feedback. On Mon, Aug 29, 2011 at 07:29:58PM +0200, Lukas Kuzmiak wrote: > I haven't patched my wireshark as the patch didn't work with latest svn > revision and I didn't really have time to patch the patch :) > I know there were questions at CCC which version was patch meant to be used > with, are there any news to this? or updates to the patch? the wireshark patch was updated to latest wiershark svn trunk during the camp. I haven't tested during the last two weeks, but I would guess it still applies... > I can participate with some more interpretations, I'll compare what I > have and what's in the patch. great, that would really be appreciated. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Tue Aug 30 07:01:13 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 30 Aug 2011 09:01:13 +0200 Subject: Any progress reports / experience with SIMtrace? In-Reply-To: <20110829200612.GA822@prithivi.gnumonks.org> References: <20110829084029.GL23789@prithivi.gnumonks.org> <20110829200612.GA822@prithivi.gnumonks.org> Message-ID: <4E5C8AB9.6080405@freyther.de> On 08/29/2011 10:06 PM, Harald Welte wrote: > > the wireshark patch was updated to latest wiershark svn trunk during the > camp. I haven't tested during the last two weeks, but I would guess it > still applies... Hi, I have also created a patch for the stable 1.6 branch (it should change a lot less). holger