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/.
Harald Welte laforge at osmocom.orgHi Merlin, On Thu, Feb 04, 2021 at 03:00:53PM +0100, merlin.chlosta+simtrace at rub.de wrote: > we try to use remsim for sharing SIMs across teams (multiple > locations). We already set up the basic SIM sharing in a VPN. Great to hear, and thanks for sharing your experience. > From a usability perspective, we’d like to have something like a SIM > inventory and select SIMs by ICCID/IMSI rather than slots. This has been raised before, but unfortunately nobody has yet contributed in that area. See https://osmocom.org/issues/3886 from two years ago. The initial design idea was to not interfere on a protocol layer with the cards, to make sure it will work for any type of smart card, not just SIM cards (EF.IMSI) or ETSI UICC compliant cards (EF.ICCID). However, I do see the usability improvements to have ICCID and/or IMSI available. It should be possible to make this completly optional, so you could enable it if you wanted, or disable it if you have a non-SIM/UICC use case. It should be implemented with the following approach: * remsim-bankd reads EF.ICCD and/or EF.IMSI at start-up (or card insertion) from every card, before the slots are used by clients * RSPRO is extended for a new, optional "CardIdentityIndication" or the like, containing those values, reported unilaterally from remsim-bankd to remsim-server * remsim-server information model is extended to keep the last IMSI+ICCID ever received for any bankd+slot tuple * RSRES JSON extended to report IMSI+ICCID whenever it lists slots One could also think of implementing this in a generic way, i.e. not have new explicit fields for IMSI + ICCID in the ASN.1 definitions and the code base, but introduce some kind of general "named attributes" whihc remsim-bankd can pass to the remsim-server. This way it would also work for any other identifiers users might want for other types of smart cards in the future. All that would be needed is to add the generation of this new "named attribute" on the bankd side. The protocol and the server would then not have to change for any new/future attributes communicated that way. Unfortunately any mechanism requires one fundamental change to how bankd works today, see https://osmocom.org/issues/3884 - but it's also "just" some work, no big challenge there... > We drafted some over-the-top service with a simple web application. > pySim reads available cards, sends them to the service and generates a > config for bankd. Kinda works, not really nice though. Indeed, it should be fully integrated. > * is there something similar already? unfortunately not. However, libosmosim (part of libosmocore.git) already contains everything needed in terms of C language library routines to perform the respective SELECT + READ BINARY commands on the cards. So at least that part doesn't have to be re-invented. > * are there similar features planned, like > * automatically reading ICCID, IMSI and sharing them through remsim service directly? > * mapping by card properties (IMSI/ICCID) instead of slot maps? The second step would go one step further beyond what I described above (merely exposing the information, but not making it a selector). I haven't yet thought on implication to RSRES interface. I guess the best approach there would be to make a proposal either here or in readmine as a feature request. In any case, we need to stay backwards compatible, so selection by additional keys such as IMSI or ICCID must be an optional addition. > We found it challenging to preserve the mappings across reboots, as > PCSC indices change. Are you referring to indicies for slots within one reader (like OCTSIM or the ACR 5-slot reader)? I haven't seen those change at all. Or are you referring to indicies for the actual readers? In that case, the recently merged https://git.osmocom.org/osmo-remsim/commit/?id=753c8aa87a2c4ad25a50230d07b183ae7194373e should be of interest to you - it introduces regex matching for PCSC reader/slot names to remsim-bankd. > Like… sharing across locations doesn’t really make sense if > plugging-in-and-out is required, and we’re not sure if e.g. connection > issues would require that. I'm not sure what exactly you are asking here, maybe you could elaborate a bit. Regards, Harald -- - Harald Welte <laforge at osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)