This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Martin Kaiser lists at kaiser.cxHi Harald,
thanks for your help.
Thus wrote Harald Welte (laforge at gnumonks.org):
> > Feb 15 22:34:44 greta kernel: [186232.651806] usb 1-1.1: new full speed
> > USB device using ehci_hcd and address 13
> > Feb 15 22:34:44 greta kernel: [186232.745566] usb 1-1.1: New USB device
> > found, idVendor=16c0, idProduct=0762
> > Feb 15 22:34:44 greta kernel: [186232.745573] usb 1-1.1: New USB device
> > strings: Mfr=4, Product=5, SerialNumber=0
> > Feb 15 22:34:44 greta kernel: [186232.745577] usb 1-1.1: Product:
> > SimTrace SIM Sniffer - Runtime Mode
> > Feb 15 22:34:44 greta kernel: [186232.745581] usb 1-1.1: Manufacturer:
> > sysmocom - systems for mobile communications GmbH
> > Feb 15 22:34:44 greta kernel: [186232.745694] usb 1-1.1: configuration
> > #1 chosen from 1 choice
> > lsusb doesn't show anything either
> that's really weird, if the kernel has recognized it and read the device
> and string descriptors, it should also show up in lsusb. The
> information lsusb uses is gathered by exactly those kernel log messages
> above.
ok, makes sense. I just noticed the line "SimTrace SIM Sniffer - Runtime
Mode".
After trying the dfu things, the behaviour is different: When I connect
phone+sim card, the board is not recognized. I see no kernel messages
and no lsusb output. When I plug in the usb with no phone/sim, then
press reset while holding the bootloader button, the board is recognized
by the kernel, identifies as SimTrace SIM Sniffer - DFU Mode and shows
up in lusb as Bus 001 Device 015: ID 16c0:0762 VOTI
> > the red led is on after connecting, simtrace (linked against libusb-1.0)
> > says "can't open USB device"
> ths was running as root? can you post a 'strace -f -s1024 ./simtrace'
> to see what's happening on a system call level?
yes, I tried runninng as root
I assume this makes no sense if the board is not in Runtime Mode? After
trying the firmware update, the board will only start in DFU Mode. Looks
like the failed dfu update erased/corrupted the firmware.
When I run simtrace while the board is in dfu mode, there's a different
error message. The board is found, but no data can be read. That's
probably what's expected when the board is in dfu mode.
root at skogar:/home/martin/src/simtrace/host# ./simtrace
simtrace - GSM SIM and smartcard tracing
(C) 2010 by Harald Welte <laforge at gnumonks.org>
Entering main loop
BULK IN transfer error; rc=-1
strace output is
...
open("/sys/bus/usb/devices/usb1/descriptors", O_RDONLY) = 8
read(8, "\22\1\0\2\t\0\0 at k\35\2\0\6\2\3\2\1\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/usb2/descriptors", O_RDONLY) = 8
read(8, "\22\1\20\1\t\0\0 at k\35\1\0\6\2\3\2\1\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/usb3/descriptors", O_RDONLY) = 8
read(8, "\22\1\20\1\t\0\0 at k\35\1\0\6\2\3\2\1\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/usb4/descriptors", O_RDONLY) = 8
read(8, "\22\1\20\1\t\0\0 at k\35\1\0\6\2\3\2\1\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/1-3/descriptors", O_RDONLY) = 8
read(8, "\22\1\0\2\357\2\1@\2\4uv\4\0\3\1\0\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/1-2/descriptors", O_RDONLY) = 8
read(8, "\22\1\0\2\t\0\1@\t\4Z\0\0\1\0\0\0\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/1-2.4/descriptors", O_RDONLY) = 8
read(8, "\22\1\0\2\t\0\1@\t\4Z\0\0\1\0\0\0\1", 18) = 18
close(8) = 0
open("/sys/bus/usb/devices/1-2.4.3/descriptors", O_RDONLY) = 8
read(8, "\22\1\0\1\0\0\0\10\300\26b\7\0\0\1\2\0\1", 18) = 18
close(8) = 0
open("/dev/bus/usb/001/018", O_RDWR) = 8
write(4, "\1", 1) = 1
read(3, "\1", 1) = 1
ioctl(8, USBDEVFS_CLAIMINTERFACE, 0x7fff79fa933c) = 0
write(1, "Entering main loop\n", 19Entering main loop
) = 19
ioctl(8, USBDEVFS_SUBMITURB or USBDEVFS_SUBMITURB32, 0x16a7a00) = -1
ENOENT (No such file or directory)
write(2, "BULK IN transfer error; rc=-1\n", 30BULK IN transfer error;
rc=-1
) = 30
ioctl(8, USBDEVFS_RELEASEINTERFACE, 0x7fff79fa933c) = 0
write(4, "\1", 1) = 1
read(3, "\1", 1) = 1
close(8) = 0
close(3) = 0
close(4) = 0
close(5) = 0
exit_group(0) = ?
> > Setting Alternate Setting #0 ...
> > Determining device status: state = dfuERROR, status = 8
> > dfuERROR, clearing status
> > Determining device status: state = dfuIDLE, status = 0
> > dfuIDLE, continuing
> > Transfer Size = 0x0100
> > bytes_per_hash=417
> > Starting download:
> > [#################################################dfu_download:
> > usb_control_msg returned -32: error sending control message: Broken pipe
> > Error during download
> that's almost at the end of the dlwonload, quite strange.
> You don't happen to have a compatible serial cable (T191, OsmocomBB,
> ...) that could be used to look at the serial console output of the
> device?
I don't have such a cable, should have ordered one along with the board.
> Also, if you have a self-powered USB hub around (i.e. with its own power
> supply), it would be interesting to see if that makes any difference.
I've just checked this, it makes no difference. The error message is
exactly the same.
Would this sam-ba mode help here? From reading the website, I understand
this is used when the bootloader is corrupted. It seems the bootloader
is ok here as the board comes up in dfu mode.
> Assuming this board was bought from sysmocom, I think after a few more
> experiments (see above) we will replace it with another one.
I'd appreciate this as a last resort.
Best regards,
Martin