the TDPU response data size can be up to 256.
this length cannot be stored in a uint8_t, which would cause the
length to become 0, no data being send, and the reader reset the
card because of misbehaviour of the card (i.e. no/malformed
response leading to the timeout of the waiting time).
Change-Id: Iae7671085aaa3115a02d82530dd7a0e7e2d4155e
RPM post-build-checks found some issue and marks these as error:
[ 61s] I: Program returns random data in a function
[ 61s] E: simtrace2 no-return-in-nonvoid-function simtrace2_usb.c:88
Change-Id: Id16fb7fc4f13176b2b6443af02a5848d8fcfb069
What we're doing is actually legal: We copy the full size of the
destination array, and then overwrite the last byte with NUL. However,
gcc isn't smart enough to see that:
libusb_util.c:162:5: warning: ‘strncpy’ specified bound 20 equals destination size [-Wstringop-truncation]
strncpy(out[out_idx].path, path, sizeof(out[out_idx].path));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Let's copy one byte less to make it happy.
Change-Id: I30ddacdc73e5245c7c38b92d1e94e39b13fae7d3
remsim also needs libpcsclite
`pkg-config --libs libosmocore` and -losmocore are duplicates
`pkg-config --libs libosmosim` is equivalent to -losmosim
pthread it needed (by most applications) for static compilation
LDFLAGS+= allows static compilation when running
LDFLAGS="-static" make
Change-Id: Ic7bd6f2be074d6f652d4f84f4996c8588ea5f851
There's still no released libosmocore defining the GSMTAP_TYPE_SIM
sub-types (Change-Id: I5bd0dff5a4a90cfe96d9c4f3dec6657e1d85bf7a
dated Jul 26, 2018).
Let's make sure users don't need an unreleased version of the library
if it's only about a few #defines that we can just copy here for
backwards compatibility.
Change-Id: I2fd9e14873711d60f194bb404420bbfbb0a00f48
After a couple of seconds of USB data exchange between remsim and
cardem, the USB transfer hangs.
On host side (remsim) I can see the USB BULK IN request.
On device side (cardem) I see that data has been submitted and
"sent" over USB, but on wireshark with USBmon I don't see the
corresponding USB BULK IN response.
When exiting remsim or just after powering of qmod (causing an
error in remsim) the USB BULK IN is show in wireshark. Thus it
must have been in a buffer, but not read by libusb_bulk_transfer.
By shortening the timeout a new libusb_bulk_transfer is made more
frequently, and the data gets read successfully.
T;his change also fixes the URB data display.
Change-Id: I1d124a41cc90893506933f6d76dc7331e52a74f9
The slot number is in the header, and correctly set in st_push_hdr.
Setting the slot in st_slot_tx_msg will overwrite the payload data.
This caused bytes three of the ATR to be changed from 0x96 to 0x00,
corrupting the ATR. This corruption is caught by the ATR checksum,
and the modem would reset the card (2 additional times) to try to
get correct ATR.
Change-Id: If971699993617fc50557d20582c344ea06645a3f
In case of error it also ensures the returned value is NULL.
Else a segfault would occur because the caller (e.g. remsim)
continued on with a free handler.
Change-Id: Ie7f20e3eff03acf77eb08283747ca8e032b9b4c8
USB addresses change every time the device re-enumerates, while the path
reflects the physical topology of USB connections and stays persistent
unless the usb cabling is changed. Let's allow the user to specify the
path instead of the address to uniquely identify a given slot.
It seems that sometimes we get even an LIBUSB_ERROR_IO and failing on
errors breaks the application, while ignoring it works. Not sure why
that really is, but for now it increases reliability.
as soon as simtrace2-remotesim is started, we issue the command to
instruct the use of the remote SIM card and ask the modem to reset
itself (to start using the new remote sim).
In current implementations, we have one interface (with it's own
separate set of USB end-points) per slot. However, the USB protocol
already includes a slot-number in the header to be able to remove that
restriction in future versions.
Also, if the USB protocol is used remotely over a network, then we could
multiplex differnt slots from different USB interfaces into one stream
on the network side.
In order to prepare the data structures in the host program, let's
introduce that logical split there, too. Might seem a bit like
overkill, but I don't want to rewrite all code later...
We want to be able to use some code irrespective of the application
(emulation, tracing, ...), so let's split the transport struct out of
the cardem_instance.
The current protocol was card-emulation specific. The new protocol is
generic/flexible enough to accommodate both tracing and card emulation,
as well as modem control and other future extensions.
Rather than using the first available interface on the first available
device, we now have a "simtrace2-list" program that lists all compatible
interfaces on all configurations of all devices on the system
When we want to run multiple instances of the card-emulator (e.g. for
multi-modem/multi-card versions of the hardware), the code shouldn't be
using any global variables but have them per-instance.
We now auto-discover the end-point addresses based on the interface
descriptor. The user can also use the new "--interface" command line
argument to set a non-zero intrerface. In combination, this should
enable support for the remote-sim functionality on the second UART
on OWHW.
Harald Welte
Kevin Redon
Martin Hauke