From holger at freyther.de Mon Mar 5 23:28:49 2018 From: holger at freyther.de (Holger Freyther) Date: Mon, 5 Mar 2018 23:28:49 +0000 Subject: MS driver: GSM tester config integration Message-ID: Hey, pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario. In terms of scenario knobs I can see: - #MS - CDF function - IMSI generator (start with XXX and count upwards) - virtphy vs. trxcon? The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config? holger From nhofmeyr at sysmocom.de Tue Mar 6 11:32:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Mar 2018 12:32:23 +0100 Subject: MS driver: GSM tester config integration In-Reply-To: References: Message-ID: <20180306113222.mxyaxraaargcywgn@ass40.sysmocom.de> On Mon, Mar 05, 2018 at 11:28:49PM +0000, Holger Freyther wrote: > Hey, > > pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario. > > In terms of scenario knobs I can see: > > - #MS > - CDF function what's CDF? > - IMSI generator (start with XXX and count upwards) We have MSISDN and I think LAC generated on-the-fly, with state in the file system. You could basically copy-paste that MSISDN generator code to make an IMSI generator. > - virtphy vs. trxcon? (no idea) > The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config? The way I see it, you implement a "copy" of the mobile.py interface to, instead of talking to ofono, talk to the virtphy/MS, whatever it's called. (Like Pau said.) Then either: - We define a limited specific number of those virtual modems in the resources.conf to be available, and add a specific trait, as in a 'type: virtual' or something. You would then add a scenario that asks for the modems to be of 'type: virtual', and run the exact tests from the existing suites, just with virtual modems instead of physical ones. - Or we could even auto-generate the entire virtual modem, sort of in the way that we start core net components at the moment, by calling a function from within the test case. For example, the osmo-msc is not a resource handled in scenarios, we just ask for IP address resources and hand one to the osmo-msc startup. Then there would be a separate *suite* with its conf not even asking for any modem resources, just its tests call a function that ask to setup virtual modems on-the-fly. A drawback here is that you can't just re-run existing suites -- you can't just swap out the physical modem kind for a virtual one and run the exact same suite, you have to write different tests that launch virtual modems from the test case script. It depends on: a) do you want to run the existing tests on the virtual modems at all? b) how physical/resource-like vs. software-component-running-like is a virtual modem? For virtual modem being a resource, I'd add only separate scenario definitions and possibly add tests to existing suites if that makes any sense; for virtual modems started up like a software component, I'd add an entirely separate suite even for the first test implemented (because then that suite wouldn't ask for 'modem' resources to begin with). BTW, in general, a virtphy issue could be the multicast. I saw stsp having some trouble keeping the multicast from seeping out of all the interfaces. We probably want the osmo-gsm-tester to contain that somehow. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pespin at sysmocom.de Tue Mar 6 12:20:11 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 6 Mar 2018 13:20:11 +0100 Subject: MS driver: GSM tester config integration In-Reply-To: References: Message-ID: Hi, I guess you are referring to my comment in [1]. You can reuse suite and resources management utilities already present in osmo-gsm-tester. The easiest way to do that would be to create a new implementation for class Modem which would start a mobile process underneath. Then in suite() when requesting a modem add a function to allocate class ModemOfono or ModemOsmoMobile based on config type, similar to how it is done for different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py). Then, you have your resources files with 300 modems: modem: - label: mobile_xyz type: osmo-mobile auth_algo: 'comp128v1' ciphers: [a5_0, a5_1] features: ['sms', 'voice', 'ussd', 'gprs'] times: 300 Then create a suite with a suite.conf containing your scenario (see suites/aoip_sms/suite.conf): resources: ip_address: - times: 6 # msc, bsc, hlr, stp, mgw*2 bts: - times: 1 modem: - times: 300 features: - sms Then, create a test which manages all those (see suites/aoip_sms/mo_mt_sms.py): #!/usr/bin/env python3 from osmo_gsm_tester.testenv import * while True: modems = [] try: # we could add a suite.get_num_resources(type='modem') API instead m = suite.modem() modems.append(m) except NoResourceExn: break; # Then do here whatever you like to do with them, like register them, etc. I think that CDF functions and IMSI generation and alike are really attach to the test and they are really not resources, so no need to "configure" them. This topic matches with your other mail thread too. We already talked with Neels about providing a set of functionality helpers and repeating code used in tests, in order to keep tests small and easy to follow. My bet here would be to have code like CDF functions which is not used internally by osmo-gsm-tester classes into this kind of library (which can be imported like from osmo_gsm_tester.testenv import *). Same goes for IMSI generation, then use modem.set_imsi(generated_imsi) or whatever before calling modem.connect(). If you want to avoid IMSI collision between consecutive tests, then add it to osmo-gsm-tester resource.py (see next_lac() for instance). About using virtphy, trxcon and all these stuff, we have the problem that the ARFCN config is still not completely arranged and implemented. I arrived to some good proposal after several patch revision with Neels, which can be found in [2], but still missing the actual implementation. The idea I have in mind would be to add an extra attribute to arfcn resources called "group" which allows to have separate groups of arfcn, for instance phy-air vs virt, but also phy-dn1 vs phy-dn2 in case we have several non colliding distributions networks (Distributed network = MS and BTS connected through wires). Then each resource playing with arfcn should have the attribute "arfcn-group: xyz" to know to which arfcn medium is it connected. This will be used by the algorithm in [2] to manage arfcn correctly or error if the combination specificed in the scenario is not possible (for instance explicitly requesting a phy BTS but only having virtphy MS). We could Add DistributionNetwork class if needed, which could be accessed and started from the different objects using them, like ms.dn() or bts.dn(). [1] https://gerrit.osmocom.org/#/c/6919/ [2] https://osmocom.org/issues/2230 -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From holger at freyther.de Wed Mar 7 16:37:14 2018 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Mar 2018 16:37:14 +0000 Subject: MS driver: GSM tester config integration In-Reply-To: References: Message-ID: <50479DDA-8C36-4408-B68E-3BB139BF6815@freyther.de> > On 6. Mar 2018, at 12:20, Pau Espin Pedrol wrote: > > Hi, Hey Neels, Pau, > I guess you are referring to my comment in [1]. You can reuse suite and resources management utilities already present in osmo-gsm-tester. The easiest way to do that would be to create a new implementation for class Modem which would start a mobile process underneath. Then in suite() when requesting a modem add a function to allocate class ModemOfono or ModemOsmoMobile based on config type, similar to how it is done for different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py). thanks to both of you for the detailed responses. I like the idea, it solves the coordination between setting up the core network and the phones. The approach looks generally feasible and I wish we had this idea earlier. Unfortunately I had only planned to do LUA bindings, the orchestration was already an extra and I blew all my time in trying to make asyncio work and the scaling/concurrency issues with python. My intention with the original mail was to find a middle step. Better integration but not full. From my point of view: Middle step: Use the test scenario configuration (maybe even the suite class). Make the UL test reusable (and extend to SMS and Calls) Big step (as proposed): The "scheduling"/slow start is not like any of the existing tests (there are conceptual difference of fail/pass handling when launching 10k procs) The event loops need to be integrated. Not sure how to integrate this with glib loop for glib-dbus? A base class for a MS (or ME) without being ofono specific and simple enough. Currently the lua JSON code is only from MS->Test. Need to add primitive to register a FD so lua can get an answer back. Find a way to set SO_PASSCRED on the socket to have "mobile" reachable by the event server as well. Could be a lua binding or we patch lua socket Have a lua script that forwards the "on/off", "limit to cell XYZ", "Send SMS", "Place Call", "Open Call and read data from this socket" Missing primitives for mobile. But we need them anyway. The middle step is in-reach, the big step will take some real time and I could use some help (e.g. the event loop integration). > I think that CDF functions and IMSI generation and alike are really attach to the test and they are really not resources, so no need to "configure" them. This topic matches with your other mail thread too. The "SIM" card would need to be in the device so IMSI kind of belongs to the resource? From pespin at sysmocom.de Wed Mar 7 17:22:42 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 7 Mar 2018 18:22:42 +0100 Subject: MS driver: GSM tester config integration In-Reply-To: <50479DDA-8C36-4408-B68E-3BB139BF6815@freyther.de> References: <50479DDA-8C36-4408-B68E-3BB139BF6815@freyther.de> Message-ID: <19169e9f-1754-103b-cbd7-4d27ee69e626@sysmocom.de> Hi Holger, > thanks to both of you for the detailed responses. I like the idea, it > solves the coordination between setting up the core network and the > phones. The approach looks generally feasible and I wish we had this > idea earlier. > > Unfortunately I had only planned to do LUA bindings, the orchestration > was already an extra and I blew all my time in trying to make asyncio > work and the scaling/concurrency issues with python. My intention with > the original mail was to find a middle step. Better integration but > not full. > I know some of the concepts in osmo-gsm-tester are quite complex to grasp (lots of specific stuff like scenarios, resources, etc.), and some of the required stuff is still missing (like better poll loop, managing arfcns, etc. we have tasks created for them). As it's quite a bit amount of work and it was not your primary focus, I don't expect to have everything done in one step. Merging it as a separate env then slowly moving it into osmo-gsm-tester seems fine for me. Personally I was also lacking a better understanding on how mobile operates and the resulting work of the lua bindings, as I didn't play with it yet. Seeing your patches helped me a lot understanding better what is there and where can we go from this first step. > > Middle step: > > Use the test scenario configuration (maybe even the suite class). > > Make the UL test reusable (and extend to SMS and Calls) What do you mean with reusable here? Can you explain it a bit more? Do you mean being able to use other Modem implementations? I agree with that. > > > Big step (as proposed): > > The "scheduling"/slow start is not like any of the existing tests (there > are conceptual difference of fail/pass handling when launching 10k procs) > > The event loops need to be integrated. Not sure how to integrate this with > glib loop for glib-dbus? I think the best would be having our own loop, which then also polls glib loop in the process. As far as I remember glib provides APIs to get poll notifications (via fd?) in case an event from them is triggered. If I recall correctly EFL libs have APIs to do that for apps which want to run efl+glib at the same time.Probably Qt guys do the same. Other possibility would be to have our own loop which is internally implemented using glib one. Having a better loop was not a hard requirement until now because we were fine without fine-grained time lapses and just active polling every 0.1 seconds, but I'd really like having a better loop. I'll try to find some time in next days to have a look at improving the current event loop. > > A base class for a MS (or ME) without being ofono specific and simple enough. > Currently the lua JSON code is only from MS->Test. I can help you with that, given that you provide all the lua specific parts. > The "SIM" card would need to be in the device so IMSI kind of belongs to the resource? An IMSI belongs to the resource, but the generator itself can be used in different tests. The IMSI field in the Modem resource is there for historical reasons (for instance if you'd like to force a specific IMSI by default), but we should rework ModemOfono to get the IMSI from ofono/dbus instead, since we are finally not using the IMSI to identify the modems but its sysfs path. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Mon Mar 12 07:57:33 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Mar 2018 08:57:33 +0100 Subject: GSM 04.08 L2 pseudo length in ACCH System Information messages In-Reply-To: References: Message-ID: <20180312075732.GN7109@nataraja> Hi Vadim, On Thu, Dec 14, 2017 at 01:57:11AM +0700, Vadim Yanitskiy wrote: > I looked at the specifications again, and found out that initially I > refered an outdated 5.3.0 version, which was the first link in Google: > > http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p.pdf > > while the latest one is 7.21.0: > > http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100940v072100p.pdf > > So, I compared the 9.1.37-40 sections of both versions, and bingo! > In the higher version ACCH System Information messages do have the > 'L2 Pseudo Length' (10.5.2.19) field. I think you have to review the matching 04.06 / 44.006 together with it. My suspicion is that earlier, 04.06 might not have specified the B4 frame format for downlink SACCH but simply used a normal B frame format (with length octet at L2). Or specified that the B4 frame format includes the length octet. It looks like what used to be a regular UI frame length octet in L2 has at some point been moved into L3 in order to achieve phase1 compatibility by having a length octet that's shorter than the payload length. Old phones will then only look at the "length" number of bytes, where newer phones will look at the full message. If they kept the length octet in L2, L2 would have automatically calculated the length to the total length of the message, including all phase2 extensions. So I guess that's why they came up with that ugly hack of defining L2 as not having a length (only addr + ctrl on downlink sacch) and the L3 including a length octet. >From the wire format point of view, you always have * two octets L1 header (power control, TA loop) * one octet ADDR * one octet CTRL * one octet [either L2 length or L2 pseudo length] * the actual L3 payloda The question is just whether you group ADDR+CTRL+LEN into L2 or you put LEN+L3 into L3. If my line of thinking is correct (see https://osmocom.org/issues/3059) we need to make sure * the L2 pseudo-length is included in all SACCH downlink L3 info on RSL, see https://gerrit.osmocom.org/#/c/7220/ * fix the wireshark dissector for SACCH, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105 * fix the wireshark RSL dissector for RSL (SACCH FILL, SACCH INFO MODIFY, CHAN ACT) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vyanitskiy at ptsecurity.com Fri Mar 16 18:05:45 2018 From: vyanitskiy at ptsecurity.com (Vadim Yanitskiy) Date: Fri, 16 Mar 2018 18:05:45 +0000 Subject: TRX toolkit - mobile app In-Reply-To: References: Message-ID: <3e32bd729ec44b77be69a16197ee618e@ptsecurity.com> Hello Victor, > I would like to congratulate and thanking you for the excellent > job you did on the osmocom TRX/gr-gsm project. Thanks. Please note that I am also CCing this message to the Osmocom baseband-development mailing list, because this info could be helpful for someone else. > I'm trying to implement into your fixeria/trx branch the ability > for mobile app to connect to a commercial network using > a SIM card into a PC/SC reader. Great. I also was going to implement this, but happy to see your efforts towards this direction. > I have a working "prototype" of an osmocom-bb (latest version) > using a PC/SC reader. I can sucessfully connect a C139 running > osmocom-bb with a commercial SIM inserted into > a PC/SC reader to its network. Please send your changes for review to gerrit.osmocom.org. I'll be more than happy to facilitate merging this work to master. See: https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit > I'm trying to import my code into osmocom TRX but I can't get mobile > working at all (even without my code) I tried using > "7fd8ef2d3f3d296a6032745396d3af8e8e3d4da2" and the last one > "4ccb2261b1ac2e207303393fe509878f160dd96b" using > "7fd8ef2d3f3d296a6032745396d3af8e8e3d4da2", It looks like mobile app > is sending Location Update Request corectly to GR-GSM but I can't sniff > it (over the air or from wireshark). > > I'm pretty sure the BTS doesn't receive it neither. > using "4ccb2261b1ac2e207303393fe509878f160dd96b", > it doesn't do anything. It's only receiving packets from PCH/AGCH. Would be great to see both logs and PCAP traces attached. I cannot say anything without knowing what is actually happening on your side, > My setup : my B200( or my B210) with GPSDO is connected trough > a commercial duplexer for the appropriate GSM band (E-GSM) > and a omnidirectional antenna. I am also using B200, but without GPSDO. Probably, your device has different delays, which causes out of sync with BTS TDMA. Piotr Krysik was working on this part, and we had an idea to implement a tool for automatical device calibration... But let's look at your logs first. > Are you able to connect the mobile app using osmocom TRX to > a network (even a test network without ciphering) ? especially > using the latest version of libosmocore/ osmocom fixeria/trx branch ? Mostly, I am working in the virtual environment - FakeTRX. Didn't try since 34c3, but it was working. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Fri Mar 16 22:33:55 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Fri, 16 Mar 2018 23:33:55 +0100 (CET) Subject: TRX toolkit - mobile app In-Reply-To: <3e32bd729ec44b77be69a16197ee618e@ptsecurity.com> References: <3e32bd729ec44b77be69a16197ee618e@ptsecurity.com> Message-ID: <59AE8918-DDF6-44AC-B917-AC5EA7ED4CEA@tomcsanyi.net> Hi all, Just a quick note: doing an attach via a PC/SC reader and commercial SIM cards is already supported via SAP. SoftSIM[1] could be used to present the card inserted into the reader using SAP (as a socket) and osmocom is capable of connecting to the socket if configured. Kind regards, Domi [1] https://osmocom.org/projects/baseband/wiki/SoftSIM 2018. m?rc. 16. d?tummal, 19:13 id?pontban Vadim Yanitskiy ?rta: > Hello Victor, > > > I would like to congratulate and thanking you for the excellent > > job you did on the osmocom TRX/gr-gsm project. > > Thanks. Please note that I am also CCing this message to the > Osmocom baseband-development mailing list, because this info > could be helpful for someone else. > > > I'm trying to implement into your fixeria/trx branch the ability > > for mobile app to connect to a commercial network using > > a SIM card into a PC/SC reader. > > Great. I also was going to implement this, but happy to see > your efforts towards this direction. > > > I have a working "prototype" of an osmocom-bb (latest version) > > using a PC/SC reader. I can sucessfully connect a C139 running > > osmocom-bb with a commercial SIM inserted into > > a PC/SC reader to its network. > > Please send your changes for review to gerrit.osmocom.org. > I'll be more than happy to facilitate merging this work to master. > See: https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit > > > I'm trying to import my code into osmocom TRX but I can't get mobile > > working at all (even without my code) I tried using > > "7fd8ef2d3f3d296a6032745396d3af8e8e3d4da2" and the last one > > "4ccb2261b1ac2e207303393fe509878f160dd96b" using > > "7fd8ef2d3f3d296a6032745396d3af8e8e3d4da2", It looks like mobile app > > is sending Location Update Request corectly to GR-GSM but I can't sniff > > it (over the air or from wireshark). > > > > I'm pretty sure the BTS doesn't receive it neither. > > using "4ccb2261b1ac2e207303393fe509878f160dd96b", > > it doesn't do anything. It's only receiving packets from PCH/AGCH. > > Would be great to see both logs and PCAP traces attached. > I cannot say anything without knowing what is actually > happening on your side, > > > My setup : my B200( or my B210) with GPSDO is connected trough > > a commercial duplexer for the appropriate GSM band (E-GSM) > > and a omnidirectional antenna. > > I am also using B200, but without GPSDO. Probably, your device > has different delays, which causes out of sync with BTS TDMA. > Piotr Krysik was working on this part, and we had an idea to > implement a tool for automatical device calibration... > > But let's look at your logs first. > > > Are you able to connect the mobile app using osmocom TRX to > > a network (even a test network without ciphering) ? especially > > using the latest version of libosmocore/ osmocom fixeria/trx branch ? > > Mostly, I am working in the virtual environment - FakeTRX. > Didn't try since 34c3, but it was working. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Fri Mar 23 13:20:22 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 23 Mar 2018 20:20:22 +0700 Subject: Proper measurement reporting Message-ID: Hi Sylvain, I am currently working on https://osmocom.org/issues/2988#note-21. And while reading the specifications and looking at the Calypso PHY implementation, I've got a few questions. In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH procedures", Measurement Report messages are sent at each possible occasion when nothing else has to be sent. In other words, a dummy LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here. The Calypso PHY (i.e. the firmware) is sending self-composed Measurement Reports if there is nothing in transmit queue: > static uint8_t ubMeas[23] = { > /* L1 SAACH pseudo-header */ > 0x0f, 0x00, > > /* lapdm header */ > 0x01, 0x03, 0x49, > > /* Measurement report */ > 0x06, 0x15, 0x36, 0x36, 0x01, 0xC0, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00 > }; > > /** > * Is called every time when when > * a new LAPDm frame received from DSP > */ > void pu_update_rx_level(uint8_t rx_level) > { > ubMeas[7] = ubMeas[8] = rx_level; > } > > const uint8_t *pu_get_meas_frame(void) > { > if (l1s.tx_meas) { > /* There is a Measurement Report in transmit queue */ > return l1s.tx_meas->l3h; > } else { > /* Compose a Measurement Report */ > /* Update L1 SAACH pseudo-header */ > ubMeas[0] = l1s.tx_power; > ubMeas[1] = l1s.ta; > > return ubMeas; > } > } I am not sure if this is the correct way. Why? - The Measurement Reports coming from the higher layers may contain additional information, such as the neighbour measurements. - The higher layers may spoof indicated TA value, while this code uses the actual one. - Measurement Reporting is already implemented in the higher layers, so this duplicates... My current ideas are: 1) Create a separate L1CTL message, that would be used to carry Measurement Reports. This way we wouldn't need to extract them from the L1CTL_DATA_REQ messages manually. 2) Keep a last Measurement Report somewhere, and transmit it until a new one is arrived from the higher layers. But I am still unsure, is this approach correct too. Probably, some parts of the Measurement Reporting implementation should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY. This way each Measurement Report would always contain the actual measurement results at the moment of transmission... What do you think? Any ideas are welcome! With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Mar 26 06:43:29 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 26 Mar 2018 08:43:29 +0200 Subject: Proper measurement reporting In-Reply-To: References: Message-ID: Hi, > What do you think? > Any ideas are welcome! TBH, Andreas wrote that part AFAIR. I don't like having duplication but it might be unavoidable to have measurement reports that are not too dated and because of the osmocom-bb latency over the serial link. I don't see much advantage in creating a new L1CTL message. I mean detecting it's a measurement report is super easy so I'd just stick with L1CTL_DATA_REQ. And AFAICT, keeping the last one and sending it until a new one arrives is pretty much what's done right now. Cheers, Sylvain From tudor007 at live.com Sun Mar 25 16:04:46 2018 From: tudor007 at live.com (Tudor Pop) Date: Sun, 25 Mar 2018 16:04:46 +0000 Subject: IMEIs Message-ID: Hi. I?m just a GSM enthusiast and pretty new on OsmocomBB project. I have some experience with OpenBTS and Range hardware (lab kit). I would like to know if running OsmoBTS, I can get instead on IMSI/TMSI pairs, only camped phone IMEIs. How can I do that? Thank you very much for helping me. Cheers, Tudor Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: