Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-11-01T21:50:15ZOpen Source Mobile Communications
Redmine Retronetworking - Feature #6244 (New): scan more/all EWS(O) documentation laforge hashttps://osmocom.org/issues/62442023-11-01T21:50:15Zlaforge
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> has multiple folders full of low-level documentation even including circuit diagrams of the EWS-O (digitally controlled bu analog switched) EWSD predecessor.</p>
<p>Part one is at <a class="external" href="https://people.osmocom.org/laforge/ftz/FTZ-161D1_14-Teil1.pdf">https://people.osmocom.org/laforge/ftz/FTZ-161D1_14-Teil1.pdf</a> but the other parts apparently are not yet scanned/released</p> Retronetworking - Feature #6237 (New): Design + Build PCBA for NE555 based fake fan rpm sensor https://osmocom.org/issues/62372023-10-30T01:38:59Zlaforge
<p>Sometimes one has to spoof fan rpm sensors.</p>
<p><a class="external" href="https://www.techidiots.net/notes/fake-fan-sensor">https://www.techidiots.net/notes/fake-fan-sensor</a> has a nice/simple design circuit. Let's build a simple PCBA around it, using parts available from JLCPCB, like</p>
<ul>
<li><a class="external" href="https://jlcpcb.com/partdetail/Hgsemi-LM555MTR/C356723">https://jlcpcb.com/partdetail/Hgsemi-LM555MTR/C356723</a> (NE555 clone)</li>
<li><a class="external" href="https://jlcpcb.com/partdetail/120172-3362P_1502/C118903">https://jlcpcb.com/partdetail/120172-3362P_1502/C118903</a> (potentiometer)</li>
</ul>
The board should have a
<ul>
<li>one or multiple 3-pin fan headers for the real fan (tacho line not connected)</li>
<li>one or multiple 3-pin fan headers (for jumper cables to mainboard)
<ul>
<li>only one of them used as power source, others have VCC disconnected</li>
<li>all of them get the same tacho signal</li>
</ul></li>
</ul> Retronetworking - Feature #6195 (New): Wiki page on Cisco *WIC-* line cards for 26xx/28xx serieshttps://osmocom.org/issues/61952023-09-27T12:47:42Zlaforge
<p>I have a large collection of various line cards (sync/async/BRI/E1/....). Let's create a wiki page about those line cards with some description and high-res PCB photographs.</p> Retronetworking - Feature #6194 (New): wiki page on MultiTech MT5600-BLhttps://osmocom.org/issues/61942023-09-27T12:46:25Zlaforge
<p>I have recently obtained three MT5600-BL 4-wire leased line modems. Let's create a wiki page with PCB photogrphs etc.</p> Retronetworking - Support #6193 (New): Replace "event rack" PM3 power supplyhttps://osmocom.org/issues/61932023-09-27T12:14:08Zlaforge
<p>Today I wanted to test the <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Event_Setup">Event_Setup</a> ahead of CC2023 and noticed that the PM3 won't power up :(</p>
<p>Luckily I have a few spare PM3 around so I could replace the broken PSU with one from another unit.</p>
<p>As I've now already seen two PM3 with broken PSU, let's make sure to replace them in all of them according to the procedure I documented in <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></p> Retrocomputing - Feature #5947 (New): Assemble PC104-SVGAhttps://osmocom.org/issues/59472023-03-15T09:29:21Zlaforge
<p><a class="external" href="https://github.com/monotech/PC104-SVGA">https://github.com/monotech/PC104-SVGA</a></p> Retrocomputing - Feature #5940 (New): Assemble LPT_Capturehttps://osmocom.org/issues/59402023-03-06T16:42:08Zlaforge
<p><a class="external" href="https://github.com/bkw777/LPT_Capture">https://github.com/bkw777/LPT_Capture</a></p> Retrocomputing - Bug #5939 (In Progress): Assemble GraphicGremlin / isavideohttps://osmocom.org/issues/59392023-03-06T16:39:24Zlaforge
<p><a class="external" href="https://github.com/schlae/graphics-gremlin">https://github.com/schlae/graphics-gremlin</a></p> Retrocomputing - Feature #5936 (New): Assemble netpi-idehttps://osmocom.org/issues/59362023-03-02T19:20:56Zlaforge
<p><a class="external" href="https://www.retrotronics.org/home-page/netpi-ide/">https://www.retrotronics.org/home-page/netpi-ide/</a></p>
<p><a class="external" href="https://www.retrotronics.org/svn/jride/trunk/">https://www.retrotronics.org/svn/jride/trunk/</a></p> Retrocomputing - Feature #5934 (In Progress): Assemble Pico-GUShttps://osmocom.org/issues/59342023-03-02T18:50:05Zlaforge
<p><a class="external" href="https://github.com/polpo/picogus">https://github.com/polpo/picogus</a></p> Retrocomputing - Feature #5933 (In Progress): Assemble XT-CF-Lite v4.1https://osmocom.org/issues/59332023-03-02T18:15:17Zlaforge
<p><a class="external" href="http://www.malinov.com/Home/sergeys-projects/xt-cf-lite">http://www.malinov.com/Home/sergeys-projects/xt-cf-lite</a></p> Retrocomputing - Feature #5932 (New): assemble ISA-USBhttps://osmocom.org/issues/59322023-03-02T17:28:00Zlaforge
<p><a class="external" href="https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter">https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter</a></p> SDR (Software Defined Radio) - Feature #5892 (Stalled): design/build ext clock input board for Pl...https://osmocom.org/issues/58922023-02-06T10:04:22Zlaforge
<p>We have a number of plutosdr devices at sysmocom, unfortunately all of them still RevB which unlike current RevD has no external clock input. Most of our use cases require a proper reference clock input, so I thought it might be a good idea to build a small board which contains the LTC6957HMS-3#PBF based input circuitry that was added in RevD. This circuit ensures that any square or sine clock can be used, at proper 50 Ohm impedance, over a wide range of levels.</p>
<p>The ext in / ext out ports should be SMA connectors, so that the resulting PCB can be panel-mounted by bulkhead-mounting those two SMA connectors to a face plate of whatever enclosure we're putting the plutosdr into.</p>
<p>The interconnect between the clock board and plutosdr can be made via u.fl as shown in <a class="external" href="https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg">https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg</a></p>
<p><a class="external" href="https://wiki.analog.com/university/tools/pluto/hacking/hardware">https://wiki.analog.com/university/tools/pluto/hacking/hardware</a></p> Retronetworking - Feature #5746 (New): Create H.221 decoderhttps://osmocom.org/issues/57462022-11-07T22:55:24Zlaforge
<p>In order to play/understand/hack ISDN video telephony, we will need a H.221 decoder as the very first stage.</p>
<p>In its basic incarnation it would need to split the 64k channel into its 8 timeslots, and perform frame + multiframe alignment, verify CRC4 and output the FAS and BAS. This should help us get a better feeling of the H.320 universe and also allow us to see what exact codecs/rates the <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/T-View_100">T-View_100</a> are using in 1B/2B mode, how the handshake at call setup time works, etc.</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> Retronetworking - Feature #5545 (New): E1 support for dynamipshttps://osmocom.org/issues/55452022-04-24T09:56:22Zlaforge
<p>It would be nice to be able to attach the dynamips emulator for Cisco hardware to real hardware, e.g. a Digium E1/T1 card or icE1usb.</p>
<p>One possible generic approach for using an entire E1/T1 trunk for HDLC/FR might be to use DADHI_NET to create hdlc devices and then open those via AF_PACKET sockets?</p>
<p>For channelized interfaces / ISDN it's of course likely more complicated.</p> Retronetworking - Bug #5512 (New): Idea: L1OIP driver for DAHDIhttps://osmocom.org/issues/55122022-04-03T11:46:45Zlaforge
<p>mISDN has <code>l1oip</code> as a protocol to use to establish virtual PRI or BRI trunks between different machines using mISDN.</p>
<p>Implementing L1OIP support in DAHDI would allow a virtual PRI/BRI line between a DAHDI machine and a mISDN machine, making it easier to user mISDN applications without the related hardware.</p> Retronetworking - Feature #5511 (New): Idea: DAHDI backend for mISDNhttps://osmocom.org/issues/55112022-04-03T11:45:08Zlaforge
<p>There are various multi-port BRI and PRI cards supported by DAHDI, which would be interesting to also get exposed to mISDN for application support.</p>
<p>I've briefly looked at the interface between mISDN core and the individual hardware drivers, and I think it would not be too hard to provide some kind of shim/adaptation so the mISDN core can use a DAHDI device.</p>
<p>In theory, this should even mean one could use CAPI applications on top of those DAHDI cards.</p> Retronetworking - Feature #5488 (In Progress): create DAHDI mirror snifferhttps://osmocom.org/issues/54882022-03-13T21:32:05Zlaforge
<p>For further exploration of a variety of different ISDN equipment and protocols, we need a proper sniffer to trace communication not only on D- but also on B-channels.</p>
Existig systems are not good use cases:
<ul>
<li>osmo-e1-recorder ("owns" the DAHDI devices/channels, for use with passive E1 tap)</li>
<li>dahdi_pcap / dahdi_gsmtap (just for D-channel)</li>
<li>dahdi_monitor doesn't work</li>
<li>dahdi_rawdump works for single B-channel only, and has no signaling integration</li>
</ul>
<p>The high-level functionality would be:</p>
<ul>
<li>open d-channel in RXMIRROR + TXMIRROR</li>
<li>filter out Q.921 I-frames in both directions (ignore everything else)</li>
<li>perform simplistic Q.931 decode of message type, call reference and IE iteration</li>
<li>maintain table with call references, one entry per callref
<ul>
<li>create on SETUP</li>
<li>destroy at RELEASE/RELEASE_COMPLET</li>
<li>destroy after timeout?</li>
</ul>
</li>
<li>decode/track ChannelID IE
<ul>
<li>store B-channel number with call reference</li>
</ul></li>
</ul>
<ul>
<li>start capturing B-channel on CONNECT</li>
<li>stop capturing B-channel when call is destroyed</li>
</ul>
<ul>
<li>optional: add software HDLC for B channel to avoid transmitting large amounts of flag octets?</li>
</ul>
<p>The data storage format could very well be the format of osmo-e1-recorder.</p> Retronetworking - Feature #5463 (In Progress): X.21 hardware interfacehttps://osmocom.org/issues/54632022-02-20T13:34:31Zlaforge
<p>It's surprising how "dead" the X.21 interface seems to be. Apart from some super expensive RS232 to X.21 converters, and the odd FarSync card on ebay, it seems it's very hard to get anything that attaches to a modern computer and implements that interface.</p>
<p>After a bit of research, it seems electrically it's not really more than 6 differential RS-422 style signals. 4 in DCE->DTE direction, and 2 in the other. I'm tempted to do a simple board with a 15pin SUB-D connector and 6 half-duplex RS-422 drivers (so the direction can be switched).</p>
<p>The transceivers of course would be 3.3V supply + logic level, so they can be used with any modern uC/FPGA/...</p>
<p>The board should be configurable for both DTE and DCE role, as well as a passive sniffer, switching all channels to receive-only.</p>
<p>Would anyone be interested in that?</p>
<p>The idea is that such an interface could then be attached to a microcontroller (or fpga) implementing the actual protocol related bits.<br />Given that I'm more of a hardware + software and not a FPGA person, I'd probably try to hook it up to an ARM based uC.</p> SIMtrace 2 - Bug #5423 (New): "trace" firmware continuous test setuphttps://osmocom.org/issues/54232022-01-27T12:24:54Zlaforge
<p>Similar to <code>cardem</code> in <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: "cardem" continuous testing setup (In Progress)" href="https://osmocom.org/issues/5422">#5422</a>, we should also create a continuous test setup for passing SIM protocol tracing. The IUT is the simtrace2 firmware.</p>
<p>We can use diffeent modems / CCID readers accessing a SIM card via a SIMtrace2 device while tracing the communication.</p> Retronetworking - Feature #4226 (New): STM-1 / USB interface?https://osmocom.org/issues/42262019-10-14T20:19:44Zlaforge
<p>This is a completeley crazy idea, but I couldn't resist doing some investigation and want to record my notes for future reference:</p>
<p>The XRT91L31 looks like an interesting chip; it does the STM-1 byte and frame alignment, as well as serial/parallel conversion. Essentially, it provides a 19.44MHz clocked 8-bit parallel input and output streaming the individual bytes. Each byte corresponds to one of the 64k sub-slots in the hierarchy. On the line-interface side it seems one can directly attach a SFP module to it.</p>
The Cypress FX2 looks like it can be used to construct a compatible interface. Its GPIF
<ul>
<li>can be clocked from the external 19.44 MHz clock recovered by the receiver</li>
<li>can interface the 8-bit parallel data and feed it from/to USB endpoints.</li>
</ul>
<p>What would be the point? One could use (inexpensive, 2nd hand) E1/E3/STM-1 add/drop multiplexers to aggregate many physical E1 interfaces and bring them into a Linux system for software switching (e.g. via a PBX like LCR or FreeSwitch).</p> SIMtrace 2 - Bug #3712 (New): TRACE_FATAL not printinghttps://osmocom.org/issues/37122018-11-27T10:57:30Ztsaitgaist
<p>TRACE_FATAL should print and enter an endless loop (until the watchdog bites).<br />currently is only does the later and no debug message is printed.<br />check if it uses the synchronous/un-buffered UART output</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> SDR (Software Defined Radio) - Bug #3126 (New): Windows 10 Pro 1709: crash of rtl_test.exehttps://osmocom.org/issues/31262018-03-30T14:16:42ZJWS
<p>Hi,<br />I fixed the following crash using rtl_test.exe:</p>
<p>Found 2 device(s):<br /> 0: å, , SN: NÚ@<br /> 1: Realtek, RTL2838UHIDIR, SN: 00000001</p>
<p>Using device 0: Generic RTL2832U OEM<br />usb_open error -12<br />Failed to open rtlsdr device #0.</p>
<p>The fix is, to use version 1.0.22 of libusb.</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 #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> 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>