- gerrit-log - lists.osmocom.org

[XL] Change in osmo-trx[master]: feat(usdr): add USDR backend support (osmo-trx-usdr)
by pespin 27 Feb '26

27 Feb '26

Attention is currently required from: Hoernchen, Timur Davydov, fixeria, laforge. pespin has posted comments on this change by Timur Davydov. ( https://gerrit.osmocom.org/c/osmo-trx/+/42198?usp=email ) Change subject: feat(usdr): add USDR backend support (osmo-trx-usdr) ...................................................................... Patch Set 4: (31 comments) Patchset: PS4: In general, I urge you to look at other existing backends like LMSDevice, UHDDevice and blade_device and try to mimic what they are doing, eg. parameter checking, lifecycle, logging, etc. Let's try to unify them as much as possible to improving something in one backend makes it possible to improve it in other easily too. File Transceiver52M/device/usdr/USDRDevice.h: https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/bbfac51e_d91e74a2?usp… : PS4, Line 12: This program is distributed in the hope that it will be useful, please keep with the "* " at the start of the line. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/9e82342d_64c3c7e5?usp… : PS4, Line 46: struct DeviceParameters { Can we use "struct dev_desc" like in all other devices I'm seeing? https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/8f72abbe_1f5cf2bf?usp… : PS4, Line 48: * time correction for TX timestamp, in seconds, to align it with RX timestamp, which is needed to achieve correct This still look like >120 chars? https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/5666b94e_9102dd6b?usp… : PS4, Line 54: using DeviceParametersMap = std::map<std::string, DeviceParameters>; Can we use dev_map_t like all other devices I'm seeing? https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/69dd1797_4c72ab51?usp… : PS4, Line 86: public: Keep order in all other device classes, where public goes first. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/6c48220d_db8f093a?usp… : PS4, Line 115: /** trailing whitespace https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/4d38b381_f3ad5bc4?usp… : PS4, Line 116: * @brief Read samples from the USDR. imho no need to re-add all the API documentation here for an implemenetation of a virtual function. I'd say remove them here and submit a separate patch improving documentation in radioDevice.h for those virtual functions. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/06e63029_8a06b71b?usp… : PS4, Line 126: bool *underrun = nullptr); align to firs tchar in "(" File Transceiver52M/device/usdr/USDRDevice.cpp: https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/bc8a6933_38b033db?usp… : PS4, Line 12: This program is free software: you can redistribute it and/or modify Please keep "* " at the start and same indentation as above. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/de1b6b46_552349cf?usp… : PS4, Line 84: if (res) { tbh I don't like exceptions being added here for no good reason. All other devices use return code checking just fine, and actually the usdr API seems to be returning that kind of errors too. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/a856e591_fce55d86?usp… : PS4, Line 191: const int loglevel = parse_config(args, "loglevel", 3); So AFAIU "loglevel" is not something one really the low level library ingests, but something you are using here to program the library. IMHO this should be controlled by vty config setting log level of DEVDRV as done in other backends, eg "log level devdrv info". Can't you actually get a callback function to be called when logging is to happen inside the library? see how it's done for instance in LMSDevice.cpp lms_log_callback(). https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/7e7e1d0c_5ab0fc62?usp… : PS4, Line 199: const double rate = 0.27083333333e6 * tx_sps; where does this magic number come from? Can we have it in a define with some comment? https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/20e60e46_480f4eef?usp… : PS4, Line 203: uint64_t val; Try putting all variable declarations at the top of the function. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/774dcff0_75523811?usp… : PS4, Line 221: usdr_dme_set_uint_exception(dev, "/dm/sdr/0/tx/gain", 0); Sounds like we may want to have all these paths applied as defines and macros instead of hardcoding them N times. eg: #define DM_SDR(idx) "/dm/sdr/" OSMO_STRINGIFY_VAL(idx) #define DM_SDR_TX_GAIN(idx) DM_SDR(idx) "/tx/gain" #define DM_SDR_RX_GAIN(idx) DM_SDR(idx) "/rx/gain" #define DM_SDR_TX_BW(idx) DM_SDR(idx) "/tx/bandwidth" #define DM_SDR_RX_BW(idx) DM_SDR(idx) "/rx/bandwidth" #define LL_DEVICE_NAME "/ll/device/name" #define LL_STX(idx) "/ll/stx/" OSMO_STRINGIFY_VAL(idx) #define LL_SRX(idx) "/ll/srx/" OSMO_STRINGIFY_VAL(idx) https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/46749fb3_75d524e4?usp… : PS4, Line 228: const char* fmt = "ci16"; this looks like a candaidate for a define too. or a const to be put at the start of the file. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/bc277d19_8652f704?usp… : PS4, Line 246: usdr_dms_sync_exception(dev, "rx", ped.size(), ped.data()); Same, we should imho avoid all these hardcoded strings. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/2487f410_a49bed6a?usp… : PS4, Line 260: if (dev) { early return: if (!dev) return; https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/69e35f29_017473a0?usp… : PS4, Line 269: return false; LOGC(DDEV, ERR) << "Device already started"; https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/f3ce2912_b2f5b2ad?usp… : PS4, Line 296: return !started; return true; https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/beffed8d_7f4fb397?usp… : PS4, Line 327: double USDRDevice::setTxGain(double dB, size_t chan) This function afacit is not used anywhere not required by base class? Leave it under "#if 0" if that's the case. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/9136098b_664bd3ec?usp… : PS4, Line 382: try { I'd say better to do as other backends are doing: Cache the values into an array per chan in eg. rx_gains, tx_gains, rx_freqs, tx_freqs, etc. Let's try to keep all backends as similar as posibble to ease maintenance and future feature development. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/7cee77c2_deb93f59?usp… : PS4, Line 392: TIMESTAMP timestamp, bool *underrun) wrong indentation https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/0bbc2246_b0a98687?usp… : PS4, Line 394: if (!started) Please look at other backends and try to mimic what they are doing, eg. checking if (bufs.size() != chans) { LOGC(DDEV, ALERT) << "Invalid channel combination " << bufs.size(); return -1; } instead of what you check here, unless there's a good reason. Let's try to keep all backends similar so it's easy to maintain. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/86e63165_9cd81e09?usp… : PS4, Line 421: bool *underrun, TIMESTAMP timestamp) wrong indentation https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/51e84e4e_6e80974d?usp… : PS4, Line 475: std::string USDRDevice::getTxAntenna(size_t chan ) extra space at the end. https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/e295efb1_39dc6a41?usp… : PS4, Line 492: return GSM::Time(6,7); missing space between "," and "7". https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/205827a9_ecce79a8?usp… : PS4, Line 610: return new USDRDevice(iface, cfg); Do extra checks here for this device in provided cfg, see LMSDevice.cpp File debian/osmo-trx-usdr.install: https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/ae98245f_98e51337?usp… : PS4, Line 3: /usr/bin/osmo-trx-usdr why do some start with / and some not? File doc/manuals/chapters/trx-backends.adoc: https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/874b912d_a11d740f?usp… : PS3, Line 86: where multiple small SDRs are combined to present one or more TRX instances > Multi-TRX deployments are achieved by running multiple osmo-trx-usdr instances, typically one per device. AFAIK this is not supported by osmo-bts-trx, one osmo-trx instance = 1 bts. Am I missing or not remembering something with regards to this topic? > the Osmocom OsmoTRX architecture operates with one TRX per osmo-trx process. No, that's not correct. OsmoTRX supports serving multiple TRX. We also support serving multiple TRX from 1 OsmoTRX in osmo-bts-trx. What we don't support is serving multiple TRX from multiple OsmoTRX in osmo-bts-trx. CC: @ewild@sysmocom.de @vyanitskiy@sysmocom.de File doc/manuals/chapters/trx-devices.adoc: https://gerrit.osmocom.org/c/osmo-trx/+/42198/comment/4b60f924_e4656939?usp… : PS4, Line 127: instances. The current _osmo-trx-usdr_ backend operates in single-channel mode. missing new line at the end of file. -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/42198?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: I5d1d25921514954c4929ae6e7352168b3ceb05df Gerrit-Change-Number: 42198 Gerrit-PatchSet: 4 Gerrit-Owner: Timur Davydov <dtv.comp(a)gmail.com> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: Hoernchen <ewild(a)sysmocom.de> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: osmith <osmith(a)sysmocom.de> Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: Timur Davydov <dtv.comp(a)gmail.com> Gerrit-Comment-Date: Fri, 27 Feb 2026 10:41:38 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: Timur Davydov <dtv.comp(a)gmail.com>

1 0

[XS] Change in osmo-remsim[master]: remsim-client: Don't attempt to pass on illegal TPDU length
by laforge 27 Feb '26

27 Feb '26

Attention is currently required from: Hoernchen, lynxis lazus. Hello Hoernchen, Jenkins Builder, lynxis lazus, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-remsim/+/42230?usp=email to look at the new patch set (#3). Change subject: remsim-client: Don't attempt to pass on illegal TPDU length ...................................................................... remsim-client: Don't attempt to pass on illegal TPDU length TPDUs with length < 5 or > 260 bytes are illegal in T=0. It doesn't make sense to send them to bankd, triggering bugs in either bankd, pcsc-lite or the CCID firmware down the road. Let's filter them right where they might originate. Change-Id: I175eb4622d0e69dbc6aca2cddfe091a78f225da5 --- M src/client/main_fsm.c 1 file changed, 5 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/30/42230/3 -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/42230?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I175eb4622d0e69dbc6aca2cddfe091a78f225da5 Gerrit-Change-Number: 42230 Gerrit-PatchSet: 3 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de> Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>

1 0

[XS] Change in osmo-remsim[master]: remsim-bankd: Don't pass on illegal TPDUs of illegal length
by laforge 27 Feb '26

27 Feb '26

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-remsim/+/42231?usp=email ) Change subject: remsim-bankd: Don't pass on illegal TPDUs of illegal length ...................................................................... remsim-bankd: Don't pass on illegal TPDUs of illegal length TPDUs with length < 5 bytes or > 260 bytes are illegal in T=0. It doesn't make sense to send them to pcsc-lite, triggering bugs in either pcsc-lite or the CCID firmware down the road. Let's filter them. Change-Id: I5c9f1143b85470234acd2e2ffe3e0cf72bd2ae43 --- M src/bankd/bankd_main.c 1 file changed, 6 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/31/42231/1 diff --git a/src/bankd/bankd_main.c b/src/bankd/bankd_main.c index 6e47376..1adc34c 100644 --- a/src/bankd/bankd_main.c +++ b/src/bankd/bankd_main.c @@ -820,6 +820,12 @@ return -106; } + if (mdm2sim->data.size < 5 || mdm2sim->data.size > 260) { + LOGW(worker, "Illegal TPDU length %u octets, not passing to driver/reader\n", + mdm2sim->data.size); + return -107; + } + rc = worker->ops->transceive(worker, mdm2sim->data.buf, mdm2sim->data.size, rx_buf, &rx_buf_len); if (rc < 0) -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/42231?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I5c9f1143b85470234acd2e2ffe3e0cf72bd2ae43 Gerrit-Change-Number: 42231 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org>

1 0

[XS] Change in osmo-remsim[master]: remsim-client: Don't attempt to pass on illegal TPDU length
by laforge 27 Feb '26

27 Feb '26

Attention is currently required from: laforge. Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-remsim/+/42230?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified-1 by Jenkins Builder Change subject: remsim-client: Don't attempt to pass on illegal TPDU length ...................................................................... remsim-client: Don't attempt to pass on illegal TPDU length TPDUs with length < 5 or > 260 bytes are illegal in T=0. It doesn't make sense to send them to bankd, triggering bugs in either bankd, pcsc-lite or the CCID firmware down the road. Let's filter them right where they might originate. Change-Id: I175eb4622d0e69dbc6aca2cddfe091a78f225da5 --- M src/client/main_fsm.c 1 file changed, 5 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/30/42230/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/42230?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I175eb4622d0e69dbc6aca2cddfe091a78f225da5 Gerrit-Change-Number: 42230 Gerrit-PatchSet: 2 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Attention: laforge <laforge(a)osmocom.org>

1 0

[XS] Change in osmo-remsim[master]: remsim-client: Don't attempt to pass on TPDU length < 5
by laforge 27 Feb '26

27 Feb '26

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-remsim/+/42230?usp=email ) Change subject: remsim-client: Don't attempt to pass on TPDU length < 5 ...................................................................... remsim-client: Don't attempt to pass on TPDU length < 5 TPDUs with length < 5 bytes are illegal in T=0. It doesn't make sense to send them to bankd, triggering bugs in either bankd, pcsc-lite or the CCID firmware down the road. Let's filter them right where they might originate. Change-Id: I175eb4622d0e69dbc6aca2cddfe091a78f225da5 --- M src/client/main_fsm.c 1 file changed, 5 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/30/42230/1 diff --git a/src/client/main_fsm.c b/src/client/main_fsm.c index dcdd239..c4c3237 100644 --- a/src/client/main_fsm.c +++ b/src/client/main_fsm.c @@ -336,6 +336,11 @@ case MF_E_MDM_TPDU: tpdu = data; OSMO_ASSERT(tpdu); + if (tpdu->len < 5) { + LOGPFSML(fi, LOGL_ERROR, "Modem submitted illegal TPDU length %u (%s), dropping\n", tpdu->len, + osmo_hexdump_nospc(tpdu->buf, tpdu->len)); + return; + } LOGPFSML(fi, LOGL_INFO, "Tx tpduModemToCard (%s)\n", osmo_hexdump_nospc(tpdu->buf, tpdu->len)); /* forward to bankd */ bank_slot2rspro(&bslot, &bc->bankd_slot); -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/42230?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I175eb4622d0e69dbc6aca2cddfe091a78f225da5 Gerrit-Change-Number: 42230 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org>

1 0

[S] Change in osmo-remsim[master]: log at NOTICE level if somebody uses loopback addresses.
by laforge 27 Feb '26

27 Feb '26

Attention is currently required from: laforge, roh. Hello Jenkins Builder, mschramm, roh, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-remsim/+/33812?usp=email to look at the new patch set (#5). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder The change is no longer submittable: Verified is unsatisfied now. Change subject: log at NOTICE level if somebody uses loopback addresses. ...................................................................... log at NOTICE level if somebody uses loopback addresses. It appears a common mistake is to e.g. run remsim-server + remsim-bankd on one machine and then instruct them to use localhost or other loopback-routed addresses. This won't work as that address is then sent to a [remote] remsim-client that attempts to reach the bankd at localhost. Change-Id: I3b4eda10e81a705aef8d647a860890a74cba8f13 --- M src/client/main_fsm.c M src/server/rspro_server.c 2 files changed, 10 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/12/33812/5 -- To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/33812?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: osmo-remsim Gerrit-Branch: master Gerrit-Change-Id: I3b4eda10e81a705aef8d647a860890a74cba8f13 Gerrit-Change-Number: 33812 Gerrit-PatchSet: 5 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: mschramm <mschramm(a)sysmocom.de> Gerrit-Reviewer: roh <jsteiger(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: roh <jsteiger(a)sysmocom.de>

1 0

[XS] Change in simtrace2[master]: Use gsmtap_inst_fd2() to remove compiler warning
by laforge 27 Feb '26

27 Feb '26

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/simtrace2/+/42228?usp=email ) Change subject: Use gsmtap_inst_fd2() to remove compiler warning ...................................................................... Use gsmtap_inst_fd2() to remove compiler warning gsmtap.c: In function 'osmo_st2_gsmtap_send_apdu': gsmtap.c:69:9: warning: 'gsmtap_inst_fd' is deprecated: Use gsmtap_inst_fd2() instead [-Wdeprecated-declarations] 69 | rc = write(gsmtap_inst_fd(g_gti), buf, gross_len); | ^~ Change-Id: I62de38175e63cb563635a01b025b805981e4b7a9 --- M host/lib/gsmtap.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/simtrace2 refs/changes/28/42228/1 diff --git a/host/lib/gsmtap.c b/host/lib/gsmtap.c index 3fc3da6..41b68fa 100644 --- a/host/lib/gsmtap.c +++ b/host/lib/gsmtap.c @@ -66,7 +66,7 @@ memcpy(buf + sizeof(*gh), apdu, len); - rc = write(gsmtap_inst_fd(g_gti), buf, gross_len); + rc = write(gsmtap_inst_fd2(g_gti), buf, gross_len); if (rc < 0) { perror("write gsmtap"); free(buf); -- To view, visit https://gerrit.osmocom.org/c/simtrace2/+/42228?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: simtrace2 Gerrit-Branch: master Gerrit-Change-Id: I62de38175e63cb563635a01b025b805981e4b7a9 Gerrit-Change-Number: 42228 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org>

1 0

[S] Change in simtrace2[master]: WIP: make 6Cxx status codes in case 2/4 ambiguous situations work
by laforge 27 Feb '26

27 Feb '26

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/simtrace2/+/42229?usp=email ) Change subject: WIP: make 6Cxx status codes in case 2/4 ambiguous situations work ...................................................................... WIP: make 6Cxx status codes in case 2/4 ambiguous situations work Change-Id: I968608e73057e9f57d3a89aae485d1a278e503e4 --- M host/include/osmocom/simtrace2/simtrace2_api.h M host/src/simtrace2-cardem-pcsc.c 2 files changed, 30 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/simtrace2 refs/changes/29/42229/1 diff --git a/host/include/osmocom/simtrace2/simtrace2_api.h b/host/include/osmocom/simtrace2/simtrace2_api.h index a29389c..baa5ed7 100644 --- a/host/include/osmocom/simtrace2/simtrace2_api.h +++ b/host/include/osmocom/simtrace2/simtrace2_api.h @@ -37,6 +37,12 @@ struct osim_chan_hdl *chan; /* path of the underlying USB device */ char *usb_path; + struct { + /* did we just send a PB=0x6C and hence need to assume case2 on re-transmit? */ + bool last_pb_was_6c; + /* cache of the last APDU header */ + struct osim_apdu_cmd_hdr last_hdr; + } state; /* opaque data TBD by user */ void *priv; }; diff --git a/host/src/simtrace2-cardem-pcsc.c b/host/src/simtrace2-cardem-pcsc.c index f26698e..5d4940d 100644 --- a/host/src/simtrace2-cardem-pcsc.c +++ b/host/src/simtrace2-cardem-pcsc.c @@ -178,6 +178,18 @@ exit(1); } + if (data->flags & CEMU_DATA_F_TPDU_HDR && ci->state.last_pb_was_6c) { + LOGCI(ci, LOGL_INFO, "==== last one was 6C\n"); + if (!memcmp(&ci->state.last_hdr, &ac.hdr, 4)) { + /* force case 2 treatment */ + LOGCI(ci, LOGL_INFO, "==== last one was 6C and hdr matches!\n"); + rc = APDU_ACT_TX_CAPDU_TO_CARD; + ac.lc.tot = 0; + } + LOGCI(ci, LOGL_INFO, "==== last_pb_was_6c => false\n"); + ci->state.last_pb_was_6c = false; + } + if (rc & APDU_ACT_TX_CAPDU_TO_CARD) { struct msgb *tmsg = msgb_alloc(1024, "TPDU"); struct osim_reader_hdl *rh = ci->chan->card->reader; @@ -193,12 +205,14 @@ } /* send to actual card */ tmsg->l3h = tmsg->tail; + LOGCI(ci, LOGL_INFO, "pcsc in: %s\n", msgb_hexdump(tmsg)); rc = rh->ops->transceive(rh, tmsg); if (rc < 0) { fprintf(stderr, "error during transceive: %d\n", rc); msgb_free(tmsg); return rc; } + LOGCI(ci, LOGL_INFO, "pcsc out: %s\n", msgb_hexdump(tmsg)); /* send via GSMTAP for wireshark tracing */ osmo_st2_gsmtap_send_apdu(GSMTAP_SIM_APDU, tmsg->data, msgb_length(tmsg)); @@ -208,6 +222,16 @@ if (msgb_l3len(tmsg)) osmo_st2_cardem_request_pb_and_tx(ci, ac.hdr.ins, tmsg->l3h, msgb_l3len(tmsg)); osmo_st2_cardem_request_sw_tx(ci, ac.sw); + /* update our state for proper handling of case2/4 distinction */ + if (ac.sw[0] == 0x6c) { + LOGCI(ci, LOGL_INFO, "==== last_pb_was_6c => true\n"); + ci->state.last_pb_was_6c = true; + } else { + if (ci->state.last_pb_was_6c) + LOGCI(ci, LOGL_INFO, "==== last_pb_was_6c => false\n"); + ci->state.last_pb_was_6c = false; + } + memcpy(&ci->state.last_hdr, &ac.hdr, sizeof(ci->state.last_hdr)); } else if (ac.lc.tot > ac.lc.cur) { osmo_st2_cardem_request_pb_and_rx(ci, ac.hdr.ins, ac.lc.tot - ac.lc.cur); } -- To view, visit https://gerrit.osmocom.org/c/simtrace2/+/42229?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: simtrace2 Gerrit-Branch: master Gerrit-Change-Id: I968608e73057e9f57d3a89aae485d1a278e503e4 Gerrit-Change-Number: 42229 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org>

1 0

[XS] Change in osmo-ccid-firmware[master]: After initialisation: turn user led on
by laforge 27 Feb '26

27 Feb '26

laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42223?usp=email ) Change subject: After initialisation: turn user led on ...................................................................... After initialisation: turn user led on Related: SYS#5158 Change-Id: Ide37ea32648536d333bd5051b142eb15959d29bf --- M sysmoOCTSIM/main.c 1 file changed, 7 insertions(+), 0 deletions(-) Approvals: laforge: Looks good to me, approved Jenkins Builder: Verified diff --git a/sysmoOCTSIM/main.c b/sysmoOCTSIM/main.c index fe569fd..74de4bf 100644 --- a/sysmoOCTSIM/main.c +++ b/sysmoOCTSIM/main.c @@ -616,6 +616,11 @@ ccid_eps_enable(); } +static inline void user_led_set(bool state) +{ + gpio_set_pin_level(USER_LED, state); +} + int main(void) { osmo_set_panic_handler(&bdg_bkptpanic); @@ -655,6 +660,8 @@ get_rstcause_str(rstcause_buf); atmel_start_init(); + user_led_set(true); + init_extpower_detect(); board_init(); usb_init(); -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42223?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: Ide37ea32648536d333bd5051b142eb15959d29bf Gerrit-Change-Number: 42223 Gerrit-PatchSet: 4 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org>

1 0

[XS] Change in osmo-ccid-firmware[master]: After initialisation: turn user led on
by laforge 27 Feb '26

27 Feb '26

Attention is currently required from: lynxis lazus. laforge has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42223?usp=email ) Change subject: After initialisation: turn user led on ...................................................................... Patch Set 3: Code-Review+2 (1 comment) Commit Message: https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42223/comment/faeffd96_ba… : PS2, Line 9: 5158 > that is an issue about osmo_ss7_vty.c ? […] Done -- To view, visit https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42223?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ccid-firmware Gerrit-Branch: master Gerrit-Change-Id: Ide37ea32648536d333bd5051b142eb15959d29bf Gerrit-Change-Number: 42223 Gerrit-PatchSet: 3 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Comment-Date: Fri, 27 Feb 2026 09:46:02 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

1 0

2026

2025

2024

2023

2022

gerrit-log