Hello!
We purchased your product (simtrace2) to produce sniff sim cards.
I did all the steps to install simtrace2 for HostPC (Preconditions,
Compiling, Accessing)
I made sure that the computer recognizes the simtrace2 device via the
simtrace2-list application.
But when the simtrace2-sniff application is launched, only the application
greeting, the usb device used and the inscription "Entering main loop" are
shown. When sending messages to a sim card, the light indicators on the
simtrace2 board start to respond to this SMS, but nothing happens in the
output of the simtrace2-sniff application on the computer.
What could be the reason for this problem?
Please help me figure it out, if possible.
Best regards, Dmitry
--
*WITH BEST WISHES *
DMITRY KRYMOV
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
June 11, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by keith: "Screen Sharing peek at TIC A.C. infrastructure in Oaxaca"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
TIC A.C. is an operator of Osmocom based community cellular networks in
indigenous communities of the Mexican state of Oaxaca. Keith works with
Rhizomatica and TIC A.C. and will give us some live insight into how
they operate
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
during the last days I've tried to setup cardem with a simtrace2 under
Manjaro/Arch and ran into some non-default problems. I've found
solutions to all of them and would like to share this :)
You'll find the detailed documentation below.
Have a great day,
Katharina
# Card Emulation on simtrace2 under Arch/Manjaro
I ran into some troubles setting everything up under Manjaro/Arch and
document the troubleshooting as follows. All of this is about card
emulation via cardem.
Problem: Using the default firmware, the phone shows "invalid SIM card"
and handing over the commercial SIM does not work.
## System and Setup
$ lsb_release -a
LSB Version: n/a
Distributor ID: ManjaroLinux
Description: Manjaro Linux
Release: 21.0.4
Codename: Ornara
1. Smart card reader in the computer, commercial SIM attached, tested
via pcsc_scan
2. simtrace2 attached to the computer via USB, tested via dfu-util
--list and ./simtrace2-list
3. Oneplus 6T, rooted, attached via nano SIM breakout
4. Remote control via adb (optional)
## Building Things
I was not satisfied with the AUR version of libosmocore and needed to
build the firmware manually, so the following documents who to first
build libosmocore, then simtrace, and then the cardem firmware.
### Libosmocore
Both AUR versions didn't really work for me, I've tested with 2 due to 1
being out of date:
2 aur/libosmocore-git 0.9.6.r165.ff20641-1 (+1 0.00)
Osmocom core library
1 aur/libosmocore 1.3.0-1 (+15 0.00) (Out-of-date: 2020-07-29)
core libs for osmocom
#### Building libosmocore
Installing the requirements was straightforward for libosmocore, so I'll
skip it here. After the requirements, follow the wiki tutorial:
git clone git://git.osmocom.org/libosmocore.git
cd libosmocore
autoreconf -fi
./configure
make
sudo make install
Then the first problem occured: although libosmocore was installed
successfully, simtrace would not find it when running ./configure:
configure: error: Package requirements (libosmocore >= 1.0.0) were not met:
Package 'libosmocore', required by 'virtual:world', not found
The reason for this is chaos in the pkgconf paths. For me, manually
adding the path did not help because the .pc files were not in the right
place:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
The solution in my case was copying the .pc files from the libosmocore
dir to the default pkgconf path:
sudo cp libosmocore/*.pc /usr/lib/pkgconfig
After that, the simtrace ./configure worked and I could build it.
#### Card Emulation
To test different firmwares, I checked out
origin/hoernchen/simtrace_cardem (others might also work) and built the
cardem firmware manually. The cross-compile process on Arch/Manjaro
introduced another problem resulting in stdlib not being found:
libosmocore/source/backtrace.c:28:10: fatal error: stdlib.h: No such
file or directory
28 | #include <stdlib.h>
| ^~~~~~~~~~
This can be fixed via
sudo pacman -S arm-none-eabi-gcc arm-none-eabi-newlib
I had arm-none-eabi-gcc installed, but only adding arm-none-eabi-newlib
solved the problem for me. After that building the firmware worked well,
in my particular setting I used
make APP=cardem BOARD=simtrace MEM=dfu
After that I could flash the firmware and the card emulation worked.
## Flashing and Runing cardem
### Preparation
Check if the simtrace is detected and get the device information:
dfu-util --list
Go to the simtrace repo:
cd Documents/Repos/simtrace2/host/src
Flash the device, --device info might need to be adjusted:
dfu-util --device 1d50:60e3 --cfg 1 --alt 1 --reset --download
path-to-repo/simtrace2/firmware/bin/simtrace-cardem-dfu.bin
After flashing, it should look like this:
./simtrace2-list
USB matches: 1
1d50:60e3 Addr=22, Path=6-1.2.3, Cfg=1, Intf=0, Alt=0: 255/2/0
(CardEmulator Modem 1)
### Running Cardem
From the wiki with some extensions:
1. power off phone
2. insert card adapter cable into phone
3. insert card adapter cable SIMtrace v2 board
4. plug SIMtrace v2 board in host computer USB port
5. connect external card reader to host (any USB CCID reader should do
the job)
6. ensure a card is present in the reader slot (not in the SIMtrace port)
7. check if the card is detected by the reader (use CTRL-C to exit)
For the next step it's important to use the correct device information
and path:
8. sudo ./simtrace2-cardem-pcsc -V 1d50 -P 60e3 -C 1 -H "6-1.2.3"
9. power on phone
After fixing all the above, I could successfully push through the
commercial SIM in the computer.
Yeeha :)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
May 28, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by fixeria: "Hacking binary protocols with Pycrate"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
May 14, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by laforge: "SS7 and SIGTRAN in 2G/3G networks"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Presentation Abstract:
This talk will cover some classic circuit-switched SS7 basics as
well as SIGTRAN (SS7 over IP) and how this is used as underlying
transport for a variety of interfaces in the 2G (GSM) and 3G
(UMTS) cellular networks even today.
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello Osmocom community,
I made some posts here earlier this year about my attempts to obtain
some programmable SIM cards from Grcard (a well-known Chinese
manufacturer of SIM and other smart cards) that are GSM SIM only,
without USIM or ISIM applications - but I just realized that I never
posted anything regarding the final outcome of those escapades. The
present post is intended to summarize what I obtained and what I
learned through that venture.
The first point to be noted is that Grcard make many bazillion
different card models, but frustratingly, they never let me see any
kind of catalog of their different offerings. Instead what happened
is that when I first approached them back in January and told them
what I was looking for in very basic terms (I simply said that I
wanted a GSM-only SIM card without any USIM or ISIM stuff), they
offered me one of their card models based on those stated requirements,
they first sent me a few sample pieces of this card model they
selected for me, and then I ended up ordering 200 pieces of that same
model with my own custom printing on the cards.
The card model which Grcard offered to me back in January and of which
I got 200 pcs a month ago in April turned out to be exactly the same
in technical terms as the one that was once sold by Sysmocom as
sysmoSIM-GR2:
https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2
As I understand it, Sysmocom had that sysmoSIM-GR2 as an offering back
in late 2013, thus it was quite surprising to see that Grcard still
readily sell that exact same model 7 and a half years later - but they
do. As a result of having done a ton of work with these cards over
the past few months, I now know a lot more about them than is said in
the scant Osmocom wiki page above, and a lot more than the little bits
of knowledge embedded in pySim code from 2013 supporting this model.
Extensive write-ups about these cards can be found in my fc-sim-tools
repository, but here is a basic summary of the good and the bad:
The good:
* These GrcardSIM2 aka FCSIM1 cards are truly native GSM 11.11 SIM,
and do not speak the unwanted-innovation UICC protocol at all.
* F=512 D=8 speed enhancement (the only SIM speed enhancement mode
called for in the original GSM 11.11 spec and the only one implemented
in most classic GSM MS hardware such as Calypso) is supported by these
cards, thus if your GSM MS firmware has this speed enhancement enabled
(at least with TI platform, many legacy fw versions have it disabled -
don't know about other GSM chipset vendors), your phone will talk to
the SIM at about 50781 bps, instead of the circa 8737 bps you get with
the basic non-enhanced F=372 D=1 mode.
* The security model on these cards works the way it is supposed to:
they initially ship with a known default SUPER ADM key, but if you
change both ADM5 and ADM11 (SUPER ADM) keys to your own secrets, then
the card becomes fully secure in the traditional SIM security sense.
I personally don't understand and will likely never understand what is
so wrong with letting your paying service subscribers know their own
Ki and letting them clone their SIM if they so wish, but if you wish
to replicate the traditional security model where you program Ki and
change ADM keys to some secret, you *can* do it with FCSIM1 cards.
Standard PIN1/PIN2/PUK1/PUK2 can be freely reset if you authenticate
with ADM5 or ADM11, but if you change those ADM keys to secrets, then
the PIN system becomes fully secure too. Contrast the situation with
Grcard's earlier model (sysmoSIM-GR1) where anyone can freely reset
both regular and ADM PINs without any authentication, meaning no
security whatsoever.
* All 3 of COMP128v1, COMP128v2 and COMP128v3 are supported. I
naturally choose COMP128v3 for my own deployments - A5/1 is weak
enough to begin with, no need to weaken it further by reducing the
effective key length to just 54 bits with COMP128v1 or v2.
* As far as I can tell, there are NO unwanted STK applications on
these cards. Harald said here earlier that Sysmocom's business
relationship with Grcard ended when Grcard started shipping cards with
some preinstalled STK applications displaying some pop-up messages in
Chinese, but I see no evidence of any such applications being present
on the FCSIM1 cards I got from them this year. I have tried issuing a
feature-generous TERMINAL PROFILE toward the card (listing support for
all common SAT features), and the SW response was 9000 - no matter
what I tried, I never got the card to respond with SW of 91xx,
indicating some proactive SIM command - thus as far as I can tell,
these SIMs never issue any proactive commands.
* The best good of all: no MOQ! Instead of being forced to buy 1000
or more cards and have them go to waste because I will never find that
many people who have the same pattern of technology likes and dislikes
as I do, I was able to buy just 200 cards - I could have ordered as
few as 100, but I ordered 200 because they were cheap - and I got those
200 cards with my own custom printing and with my choice of form factor
cut - I chose 2FF-only, of course.
The bad:
* The free reformatting ability that existed on sysmoSIM-GR1 has been
taken away. On sysmoSIM-GR1 you could erase the card file system and
recreate your own tree of DFs and EFs according to your own liking
(with you deciding which files to include or omit, what size to
allocate for each file, and what access conditions it should have),
but those proprietary APDU commands from GR1 don't work on GrcardSIM2
(FCSIM1), and the official answer from Grcard is that such downstream
reformatting is not allowed. I am guessing that what I want probably
*can* be done by reformatting the card flash and reloading their
CardOS at a lower level, but needless to say, Grcard won't divulge any
of the knowledge that would be needed for such an endeavor.
* The fixed formatting these cards came with (which we have no way of
changing per above) is far from ideal: EF_AD is only 3 bytes and not 4,
some files that aren't absolutely critical but would be nice to have
like SDN and ECC are missing, and the allocated record size for EF_ADN
is only 28 bytes, allowing only 14 characters for the contact name
field. Contrast with old T-Mobile USA SIMs that have 44-byte ADN
records (30 characters for contact name), or current Sysmocom cards
that have 34-byte ADN records, allowing 20 characters. Grcard people
told me that they can change this file system layout to a different
one with MOQ of 10000 pcs, but of course such MOQs are absolutely not
acceptable for "just for love" applications like mine.
* There is no OTA programming capability on this card model. I was
hoping that I could program EF_MSISDN over the air (yes, I know full
well that a phone doesn't need to know its own MSISDN to make or answer
calls, but all classic GSM phones have a menu command for "Show my
number" or whatever it's called, and that's what EF_MSISDN on the SIM
is for) like I can do on sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards, but
nope, this functionality just isn't there. Grcard folks were telling
me that they have some other card model that supports OTA, but I never
got a straight answer out of them as to whether that other card model
is also GSM SIM only, or if it is UICC/USIM/ISIM - I suspect the
latter, which would be totally uninteresting to me.
* The worst badness of all is that Grcard people absolutely hate
customers who ask too many technical questions, and when pressed, they
typically respond only with non-answers. There is basically NO
technical support of the kind we got used to in highly technical
communities like Osmocom with vendors like Sysmocom, instead they are
used to dealing with sales and marketing types. I also got the
impression that selling to R&D customers is very foreign to them,
instead they are set up for making cards for operator/MVNO type of
customers who let the card vendor do all of the programming at the
factory and don't get into any real technical stuff themselves.
So here is what we got:
https://www.freecalypso.org/members/falcon/pictures/SIMs/FCSIM1_front.jpeghttps://www.freecalypso.org/members/falcon/pictures/SIMs/FCSIM1_back.jpeg
The cards depicted in those photos are quite real, they are sitting
right here at my FreeCalypso HQ in California, and they work in the
sense that I can program everything including IMSI, Ki and COMP128v3
selection. I haven't set up my own GSM network yet - I already
acquired a couple of nanoBTS units (one for 850 MHz, one for 1900 MHz),
but I still need to acquire a better server machine for running
Osmocom CNI software.
Much like any other feeling and soulful human, I have a deep-rooted
urge to share my work with others. When it comes to the present SIM
card venture, I am doing everything I can to share my work with the
community in 3 ways:
1) The software I developed for programming these cards is free to the
world, with an explicit public domain license statement:
https://www.freecalypso.org/hg/fc-sim-tools/
My fc-sim-tools suite is a direct competitor to pySim, written in C
instead of Python, and split into separate fc-simtool and fc-uicc-tool
for the two very different protocols that exist for talking to SIM
cards. Oh, and my tools can be used to program Sysmocom webshop cards
too, not just my Grcard-based FCSIM1.
2) If anyone else would like to buy similar cards from Grcard, I will
be happy to put you in touch with my contact there and guide you through
the process - and by encouraging anyone with a commercial interest to
buy directly from Grcard instead of me acting as a reseller, I
explicitly disavow any thought of commercially profiting from any
related venture or acting as any kind of commercial entity myself.
3) If there is anyone in the world who shares my core philosophical
position whose wording is imprinted on the plastic on my FCSIM1 cards
(see the pictures above) and would like to get a few of these cards,
please let me know, and I will be glad to send you however many cards
you need, for the cost of shipping only, or at most covering my own
cost of ordering more cards in the highly unlikely event that I get
enough interest to run down my stock.
In hacking fellowship,
Mother Mychaela
Hasta la Victoria, Siempre - 2G forever!
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
April 23, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by horiz0n: "YIG & YANG (Yet ANother yiG driver)"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Presentation Abstract:
This talk will briefly introduce the working principles of YIG
(Yttrium Iron Garnet) microwave circuits, their applications and
finally conclude with a presentation of a recently developed driver
circuit.
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
April 9, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation: pySim-shell - the next generation of pySim
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Presentation Abstract:
For more than a decade, pySim-prog has been the tool to
configure/program SIM cards in research/lab/private cellular
networks. Originally designed for very simplistic GSM-only SIM
Cards, it was extended again and again to cover more use cases
and parameters. There is a limit as to how far one can go with
stuffing everything into command line arguments.
In 2021, pySim-shell was created as the next generation tool. It
features interactive navigation around the file system, editing
capabilities, backup and restore of all [known] files, ...
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
pySim-prog was nice when there were only 5 parameters on a SIM that we
could program, and where the use case was pretty limited. Today, we
have SIM/USIM/ISIM cards with hundreds of files and even more parameters
to program. We cannot add a command line argument for each file to
pySim-prog.
Instead, this introduces an interactive command-line shell / REPL,
in which one can navigate the file system of the card, read and update
files both in raw format and in decoded/parsed format.
The idea is primarily inspired by Henryk Ploetz' venerable
cyberflex-shell, but implemented on a more modern basis using
the cmd2 python module.
You can see the very first prototype in the laforge/shell branch of pysim.git
You can do things with it like this:
===> Start-up and authenticate with adm pin
----------------------------------------------------------------------
$ ./pysim-shell.py -p 0
Using PC/SC reader interface
Autodetected card type: sysmoISIM-SJA2
AIDs on card: ['a0000000871002ffffffff8907090000', 'a0000000871004ffffffff8907090000']
Welcome to pySim-shell!
pySIM-shell (3f00)> verify_adm 92990895
----------------------------------------------------------------------
===> interactive help
----------------------------------------------------------------------
pySIM-shell (3f00)> help
Documented commands (use 'help -v' for verbose/'help <topic>' for details):
ISO7816 Commands
================
read_binary select_adf select_file update_binary update_record verify_chv
pySim Commands
==============
intro verify_adm
USIM Commands
=============
read_ehplmn ust_service_activate ust_service_deactivate
pySim-shell built-in commands
=============================
alias help macro quit run_script shell
edit history py run_pyscript set shortcuts
----------------------------------------------------------------------
===> more interactive help
----------------------------------------------------------------------
pySIM-shell (3f00)> help read_binary
usage: read_binary [-h] [--file-id FILE_ID] [--offset OFFSET] [--length LENGTH] [--record-nr RECORD_NR]
Read binary data from a transparent EF
optional arguments:
-h, --help show this help message and exit
--file-id FILE_ID File ID
--offset OFFSET Byte offset for start of read
--length LENGTH Number of bytes to read
--record-nr RECORD_NR
Number of record to read
----------------------------------------------------------------------
===> navigating the FS and reading files
----------------------------------------------------------------------
pySIM-shell (3f00)> select_file 7f20
['622c8202782183027f20a509800171830400018d088a01058b032f0601c60f90017083010183018183010a83010b']
pySIM-shell (3f00/7f20)> read_binary --file-id 6f07
089910070000400310
----------------------------------------------------------------------
===> interaction with local filesystem, i.e. I/O redirect + shell commands
----------------------------------------------------------------------
pySIM-shell (3f00)> select_adf a0000000871002
pySIM-shell (a0000000871002)> select_file 5f3b
pySIM-shell (a0000000871002/5f3b)> read_binary --file-id 4f20 > /tmp/f
pySIM-shell (a0000000871002/5f3b)> !cat /tmp/f
ffffffffffffffff07
----------------------------------------------------------------------
===> piping output through shell tools like grep
----------------------------------------------------------------------
pySIM-shell (3f00)> read_ust | grep 86
Service 86 - Allowed CSG Lists and corresponding indications
----------------------------------------------------------------------
===> enabling/disabling services
----------------------------------------------------------------------
pySIM-shell (3f00/7f20)> ust_service_activate 123
pySIM-shell (3f00/7f20)> ust_service_deactivate 123
----------------------------------------------------------------------
It's a very first prototype, but it is really promising.
The major tasks I see to make this go anywhere is:
* have "File" class with encoder/decoder methods, which are registered
automatically with a 'file system' layer that knows about the DF/ADF
hierarchy
** this allows us to have a "read-decoded" command, which will
call the decode method of the file, automatically resolved by the
selected FID/path
* automatic mapping of file-name -> FID and FID -> file name
** when printing (like in the path), use the human-readable names
** allow users to use human-readable names in SELECT
* decode + display the TLVs / FCPs after a SELECT (like cyberflex-shell
* ability to enable/disable APDU trace
* dynamically register/deregster commands based on the path, i.e. offer
USIM commands only when in ADF_USIM
We have quite a bit of that infrastructure in the c-language libosmosim,
(part of libosmocore.git), but unfortunately not in python :/
Let me know if anyone is interested in joining this effort.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
This topic has been past due for way too many years by now:
A re-organization of our major mailing lists.
I would like to propose the following changes. Pleas let me know if you
have any comments or feedback. I'm aware that renaming will mean people
have to update their mail filter rules, but I think we're long past the
point where the names of some of our lists started to confuse users.
== openbsc(a)lists.osmocom.org ==
* openbsc doesn't exist anymore since OsmoNITB, which is also obsolete
* does already cover anything "Osmocom CNI" related
* Proposed new name: osmocom-cni(a)lists.osmocom.org
== osmocom-net-gprs(a)lists.osmocom.org ==
This date back to when GPRS was a highly experimental add-on to our GSM
code base. This list should simply be merged with openbsc@ as osmocom-cni(a)lists.osmocom.org
== simtrace(a)lists.osmocom.org ==
Historically was created to cover only the simtrace project.
We should rename this to osmocom-simcard(a)lists.osmocom.org or something
along those lines.
I would like to suggest it covers
* SIMtrace / SIMtrace2 hardware + firmware
* pySim and related tools for working with SIM/USIM/UICC cards
* any other information / discussion related to SIM/USIM/UICC cards,
like OTA, ARA-M, ...
== osmodevcon(a)lists.osmocom.org ==
This has been a private list for people attending OsmoDevCon
I would like to open up list membership to the general public, and ensure
it also covers the new OsmoDevCall. We could then have discussions regarding
feedback, topics, scheduling, etc. on that list.
Maybe rename it to osmocom-events(a)lists.osmocom.org instead?
To differentiate: osmocom-event-orga(a)lists.osmocom.org should remain a
private list related to organizational / administrative topics of those
involved with organizing future events.
== nextepc(a)lists.osmocom.org ==
Should have been renamed to open5gs(a)lists.osmocom.org quite some time
ago, I simply forgot about it. My apologies.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
