Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092022-11-30T11:52:04ZOpen Source Mobile Communications
Redmine SIMtrace 2 - Feature #5805 (New): SIM Trace 2 Build for Windowshttps://osmocom.org/issues/58052022-11-30T11:52:04Zjelson_simEng
<p>Hello all,</p>
<p>I have been working on trying to have SIMTrace2 build for windows.<br />I am checking just in case someone has already done that and has something that might share.</p>
<p>Thank you,<br />Jelson G.</p> SIMtrace 2 - Bug #5639 (Feedback): No packet captured but only "Card state change:"https://osmocom.org/issues/56392022-07-31T16:18:56Zg1bbs
<p>Hello, I'm facing a problem when using the trace function. It doesn't capture any packets and the phone (iphone se/iphone xs) shows "No SIM card".</p>
<p>I used the latest version firmware, flashed with dfu-util. I inserted the valid sim card into the simtrace board, inserted the cable-sim into the phone, start the sniff program and turn on the phone. But it keep output "Card state change:". Is it a bug or my problem? Thanks!</p>
<p>(the board version on the back is v1.5 with ATSAM3SD8B chip)</p>
<p>Here's the console output when flushing.
*<strong><b></strong>*</b>**<strong>**</strong>*******************************<br />test@1-NUC8i7BEH:~/SIMtrace$ sudo dfu-util --device 1d50:60e3 --cfg 1 --alt 1 --reset --download simtrace-trace-dfu-latest.bin <br />dfu-util 0.8</p>
<p>Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.<br />Copyright 2010-2014 Tormod Volden and Stefan Schmidt<br />This program is Free Software and has ABSOLUTELY NO WARRANTY<br />Please report bugs to <a class="email" href="mailto:dfu-util@lists.gnumonks.org">dfu-util@lists.gnumonks.org</a></p>
<p>dfu-util: Invalid DFU suffix signature<br />dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!<br />Opening DFU capable USB device...<br />ID 1d50:60e3<br />Run-time device DFU version 0100<br />Claiming USB DFU Runtime Interface...<br />Determining device status: state = appIDLE, status = 0<br />Device really in Runtime Mode, send DFU detach request...<br />Device will detach and reattach...<br />Opening DFU USB Device...<br />Claiming USB DFU Interface...<br />Setting Alternate Setting <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> ...<br />Determining device status: state = dfuIDLE, status = 0<br />dfuIDLE, continuing<br />DFU mode device DFU version 0100<br />Device returned transfer size 512<br />Copying data from PC to DFU device<br />Download [=========================] 100% 23532 bytes<br />Download done.<br />state(7) = dfuMANIFEST, status(0) = No error condition is present<br />state(2) = dfuIDLE, status(0) = No error condition is present<br />Done!<br />dfu-util: can't detach<br />Resetting USB to switch back to runtime mode</p>
<p><strong><b>the console will stuck here</b></strong><br />------------------------------------------------</p>
<p>Here's the console output when tracing.
*<strong><b></strong>*</b>**<strong>**</strong>**********************************<br />test@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ ./simtrace2-list <br />USB matches: 2<br /> 1d50:60e3 Addr=6, Path=1-4, Cfg=1, Intf=0, Alt=0: 255/1/0 (SIMtrace Sniffer)<br /> 1d50:60e3 Addr=6, Path=1-4, Cfg=2, Intf=0, Alt=0: 255/255/0 (0.8.1.36-a5d53)<br />test@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ sudo ./simtrace2-sniff <br />simtrace2-sniff - Phone-SIM card communication sniffer <br />(C) 2010-2017 by Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>><br />(C) 2018 by Kevin Redon <<a class="email" href="mailto:kredon@sysmocom.de">kredon@sysmocom.de</a>></p>
<p>Using USB device 1d50:60e3 Addr=6, Path=1-4, Cfg=1, Intf=0, Alt=0: 255/1/0 (SIMtrace Sniffer)<br />Entering main loop<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />^Ctest@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ sudo ./simtrace2-sniff <br />simtrace2-sniff - Phone-SIM card communication sniffer <br />(C) 2010-2017 by Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>><br />(C) 2018 by Kevin Redon <<a class="email" href="mailto:kredon@sysmocom.de">kredon@sysmocom.de</a>></p>
<p>Using USB device 1d50:60e3 Addr=6, Path=1-4, Cfg=1, Intf=0, Alt=0: 255/1/0 (SIMtrace Sniffer)<br />Entering main loop<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />^Ctest@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ <br />------------------------------------------------</p> SIMtrace 2 - Bug #5578 (Stalled): osmo-remsim-client-st2 hangs after usb-reset without power loss...https://osmocom.org/issues/55782022-06-15T21:50:45Zroh
<p>in case of a osmo-remsim-client-st2 session which gets restarted after being stopped by a usb-disconnect<br /> (terminates with "DST2 FATAL user_simtrace2.c:221 USB IN transfer failed, status=1" as expected)</p>
<p>osmo-remsim-client-st2 gets stuck and then terminates after some time:</p>
<pre>
root@raspberrypi:~# /usr/bin/osmo-remsim-client-st2 -i 10.15.1.135 -V 1d50 -P 4004 -C 1 -I 0 -H 1-1.3.1 -c 1 -n 0
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9998
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE input/ipa.c:128 10.15.1.135:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 10.15.1.135:9998 UP
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9999
DLINP NOTICE input/ipa.c:128 10.15.1.135:9999 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(bankd){REESTABLISH}: RSPRO link to 10.15.1.135:9999 UP
DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 00 )
DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f 87 80 31 e0 73 fe 21 1b 67 4a 4c 75 30 34 05 4b a9 )
DST2 INFO user_simtrace2.c:65 SIMtrace => PTS req: ff 10 96 79 00 00
...
<modem starts, usb enumeration of serials/wwlan>
...
USB OUT transfer failed, status=2
</pre>
<p>later restarts remain the same in behaviour but a bit different in output:</p>
<pre>
root@raspberrypi:~# /usr/bin/osmo-remsim-client-st2 -i 10.15.1.135 -V 1d50 -P 4004 -C 1 -I 0 -H 1-1.3.1 -c 1 -n 0
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9998
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE input/ipa.c:128 10.15.1.135:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 10.15.1.135:9998 UP
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9999
DLINP NOTICE input/ipa.c:128 10.15.1.135:9999 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(bankd){REESTABLISH}: RSPRO link to 10.15.1.135:9999 UP
DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 00 )
DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f 87 80 31 e0 73 fe 21 1b 67 4a 4c 75 30 34 05 4b a9 )
USB OUT transfer failed, status=2
</pre>
<p>please note that the modem does not seem to reboot on later restarts of osmo-remsim-client-st2, which is odd.</p>
<p>osmo-remsim-client version 1.0.0.18-f5f5<br />qmod firmware 0.8.1.33-9088</p>
<p>osmo-remsim-bankd version 1.0.0.18-f5f5<br />osmo-resmim-server version 1.0.0.18-f5f5</p>
<p>maybe this is a rerun of <a class="issue tracker-1 status-7 priority-1 priority-lowest" title="Bug: osmo-remsim-client-st2 (or firmware?) gets stuck on PTS (Stalled)" href="https://osmocom.org/issues/4409">#4409</a></p>
<p>for this test the server/bankd were on x86_64 and the client was on armv7l (rpi) but i don't think it matters.<br />i have also tried a older qmod firmware (0.7.0.57-f46d) for comparison but i can see no difference in behavior.</p>
<p>please note that i could not reproduce this issue with a modem on st34, only on st12. i suspect it has to do with st12 staying powered all the time and not reset/rebooted on usb-connect properly somehow.</p>
<p>this may as well be a firmware issue on the qmod.</p> SIMtrace 2 - Bug #4118 (New): VCC_PHONE strong pull on SIMtrace boardhttps://osmocom.org/issues/41182019-07-18T11:54:10Ztsaitgaist
<p>A complex behavior I identified while testing card emulation:<br />- although the phone does not power the card (the SIMtrace board, v1.4) through VCC_PHONE, VCC_PHONE was at 3.2V (after power up)<br />- VCC_PHONE should be pulled down by R19 (100k resistor)<br />- VCC_PHONE is also connected to the FLAGB output of the FPF2109. but this output is only an open-drain (can't drive high), and connected through a 100k resistor R22 (driving high could not be strong enough to set VCC_PHONE to 3.2V)<br />- when VCC_PHONE is briefly shorted to ground (pulling low with less than 1kR), VCC_PHONE then goes and stays at 0.6V</p>
<p>the issue comes from the FPF2109.<br />VCC_PHONE is connected to VIN, which should only be an input. VCC_SIM is connected to VOUT, which should only be an output.<br />VCC_SIM is also the output of the AP7332 voltage regulator.<br />the output from AP7332 goes in FPF2109 as VCC_SIM, through the FPF2109 internal MOSFET body diode (presumably), back out to VCC_PHONE.<br />the FPF2109 has an internal reverse blocking mechanism. this is probably kicking in when VIN is shorted to ground. 0.6V still pass through.</p>
<p>this is an issue because holding VCC_PHONE high prevents the firmware to properly detect activation (power up) and cold reset of the card.<br />some card readers pull/drive VCC low (omnikey 6321), but I'm not sure all modems do.</p>
<p>TODOs:<br />- R22 is not needed and can be removed (the FLAGB output is not used)<br />- the R19 pull down resistor is also not needed since R20+R21 (resistor divider) already form a 20k pull down resistor<br />- ensure the on-board regulator for VCC_SIM is switched off<br />- switching the regulator off would prevent using SIMtrace as independent card reader while card emulation is used (this is not an issue for MitM since the phone powers the card when needed)<br />- better find out/test how the reverse current protection works</p> UmTRX - Feature #3747 (New): LMS6002D RX Gain Controlhttps://osmocom.org/issues/37472019-01-08T02:53:19Zjahredibanez
<p>Hi, with OSMO Rx-Gain Setting for UmTRX</p>
<p>osmotrx rx-gain <0-50><br />Set the receiver gain (configured in the hardware) in dB</p>
<p>LMS6002D Transceiver has gain blocks for RXLNA, RXVGA1, RXLPF, and RXVGA2.</p>
<p>which block does this setting change? and how does it change these values?</p> SIMtrace 2 - Feature #3711 (New): Add screw holes for permanent installationshttps://osmocom.org/issues/37112018-11-27T02:04:29Zgnutoo
<p>The remote SIM functionality enables to use SIMtrace 2 to do things like functional testing of smartphones, for instance to do regression testing or to fix bugs on the free software code that talks to its modem.</p>
<p>In such permanent installation setup, it would be better to be able to permanently screw it (through standoffs, screws, and bolts).</p>
<p>As for keeping the smartphone in place, it's probably trivial to do that with a smartphone case.</p> SIMtrace 2 - Feature #3501 (New): Multi-sim addon board ideahttps://osmocom.org/issues/35012018-08-26T18:12:10Zdemodulate
<p>If the SIMTrace2 board is redone, I would like to propose that the bottom of the board, or free space on the board, is used to hold additional SIM slots with the understanding that only one slot would be used at any given point in time. A single LED could indicate which SIM is in use, if the SIM selection used a software controlled switch. Alternatively, a second board could be created as an add on to hold any number of SIMs based on the area of the board. A physical slider switch for selecting the electrical path would be suitable in either case.</p>
<p>Would this be useful for anyone using the SIMTrace2?</p> Z-Netz - Feature #2814 (New): Create + Document classic CrossPoint setup on DOS (dosemu)https://osmocom.org/issues/28142018-01-01T13:41:48ZlaforgeZ-Netz - Feature #2813 (New): Create + Document OpenXP setup on Linuxhttps://osmocom.org/issues/28132018-01-01T13:41:26ZlaforgeZ-Netz - Bug #2809 (New): Build ZConnect <-> UseNet gatewayhttps://osmocom.org/issues/28092018-01-01T13:09:32Zlaforge
<p>possibly looking at <a class="external" href="https://www.daneben.de/odoconnect.html">https://www.daneben.de/odoconnect.html</a> as a tool</p> Z-Netz - Bug #2808 (New): Create + Document VM/emulation setup for running ZERBERUShttps://osmocom.org/issues/28082018-01-01T13:09:06ZlaforgeZ-Netz - Bug #2807 (Stalled): Obtain ZERBERUS software build[s] and manual[s]https://osmocom.org/issues/28072018-01-01T13:08:48Zlaforge
<p>I've sent mail to padeluun + rena about this.</p> UUCP and UseNet - Feature #2806 (New): Create Dockerfile and/or ansible playbook for UseNet nodehttps://osmocom.org/issues/28062018-01-01T13:04:27Zlaforge
<p>Should be possible using stock debian packages for taylor UUCP, inn2, exim, ...</p> SIMtrace 2 - Feature #1912 (Stalled): do proper re-layout of the boardhttps://osmocom.org/issues/19122017-01-12T12:55:08Zlaforge
<p>SIMtrace v1 PCB layout has been serving us well, but is far from ideal in terms of RF return paths and signal integrity.</p>
<p>Let's revisit that when doing a v2 of the hardware</p> SIMtrace 2 - Feature #1911 (New): check if we can have an enclosed version of simtrace v2https://osmocom.org/issues/19112017-01-12T12:52:40Zlaforge
<p>It would be nice to have an enclosed device rather than a bare PCB. Let's review that option for v2 hardware.</p> SIMtrace 2 - Feature #1706 (In Progress): Hardware / Circuit board update for SAM3S based SIMtrac...https://osmocom.org/issues/17062016-05-09T19:48:06Zlaforge
<p>We have a few boards using SAM3S instead of the old SAM7S, and just changing the chip + firmware while keeping the rest of the hardwrare seems fine.</p>
<p>However, we might want to add some other features to the board, while we are doing the switch to SAM3S.</p> UmTRX - Feature #1518 (New): Upper limit of the clock is too lowhttps://osmocom.org/issues/15182016-02-19T22:52:49Z
<p>Upper limit of the clock is too low.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1517 (New): U_FL (UMC) connectors are not reliable after few connectionshttps://osmocom.org/issues/15172016-02-19T22:52:49Z
<p>U_FL (UMC) connectors are not reliable after few connections.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1516 (New): There are no port to control external equipment like PAhttps://osmocom.org/issues/15162016-02-19T22:52:49Z
<p>There is no port to control external equipment such as a PA.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1515 (New): Heat dissipation and mounting issuehttps://osmocom.org/issues/15152016-02-19T22:52:49Z
<p>Heat dissipation and mounting issue.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1509 (New): Store calibration values in EEPROMhttps://osmocom.org/issues/15092016-02-19T22:52:48Z
<p>Store calibration values in EEPROM.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1510 (New): Complete UHD integrationhttps://osmocom.org/issues/15102016-02-19T22:52:48Z
<p>Complete UHD integration.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Bug #1505 (New): OHM4 footprint incorrecthttps://osmocom.org/issues/15052016-02-19T22:52:48Z
<p>OHM4 footprint incorrect.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1508 (New): Implement UmSEL diversity switch controlhttps://osmocom.org/issues/15082016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> diversity switch control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1507 (New): Implement UmSEL tuner controlhttps://osmocom.org/issues/15072016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> tuner control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1506 (New): Move to the latest stable UHDhttps://osmocom.org/issues/15062016-02-19T22:52:48Z
<p>Move to the latest stable UHD.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1511 (New): Solve Tx and Rx I/Q imbalance for wideband signalshttps://osmocom.org/issues/15112016-02-19T22:52:48Z
<p>Solve Tx and Rx I/Q imbalance for wideband signals.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1504 (New): LMS6002 phase error increases when Rx is enabled and varies with tem...https://osmocom.org/issues/15042016-02-19T22:52:47Z
<p>LMS6002 phase error increases when Rx is enabled and varies with temperature.</p>
<p>[Migrated from old Google Code tracker]</p> SIMtrace 2 - Feature #1457 (New): Spacing between JTAG and JP1/JP2https://osmocom.org/issues/14572016-02-19T22:48:42Z
<p>On v1.0 and v1.1 the spacing between JTAG and JP1/JP2 (erase, test) could be higher. Right now the JTAGkey is a bit blocked by JP1/JP2.</p> SIMtrace 2 - Feature #1463 (New): Add VCC current sensing circuit for SPA & DPA attackshttps://osmocom.org/issues/14632016-02-19T22:48:42Z
<p>It would be pretty good to be able to sense current going to the SIM.</p>
<p>The simple idea is to measure current like this :</p>
<pre>
A B
o o
| |
pwr >----/\/\/\----> to SIM
|
=
|
#
</pre>
<ul>
<li>Ideally use a '4 wire' resistor to make sure you have precision measurement.</li>
<li>Choose value appropriately depending on a typical smart card power consumption.</li>
</ul>
<p>Now, I would include added circuitery to make measurements easier.<br />Because in the simple form there are a couple of issue:</p>
<p>First the signal is gonna be pretty small.<br />Second is that to measure the current across the resistor you can't just put the gnd of your probe on A and the tip on B. That's because the GND of the scope is connected to earth of the mains supply, which in turn is connected to the GND on the PC and so the GND of the simtrace ...</p>
<p>You can either:<br /> - Use two scope probe and use A - B function but this has often less functions that a single probe channel. Also if you only have a 2 channel scope you can't monitor anything else (like the clk line or something).<br /> - Simply probe one point: But then you have the supply noise added to your measurement noise and you don't have absolute values.<br /> - Use a differential probe: Great option ... if you have a couple more k$ to buy one.</p>
<p>So ... all of these suck.</p>
<p>We could have an difference amplifier onboard, however, finding one with multi-MHz bandwidth isn't trivial and they all need dual power rails.</p>
<p>(sorry for the rambling, I'm thinking while writing the ticket ...)</p>
<p>Note that since this feature in its more advanced form may involve expensive / complex components and only be used by very few people. so it could be mounted as a simple 0R with other pad left to be mounted manually by the interested parties.</p>