From laforge at osmocom.org Wed Mar 3 09:00:06 2021 From: laforge at osmocom.org (Harald Welte) Date: Wed, 3 Mar 2021 10:00:06 +0100 Subject: Osmocom Mailing List re-organization Message-ID: 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 at 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 at lists.osmocom.org == osmocom-net-gprs at 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 at lists.osmocom.org == simtrace at lists.osmocom.org == Historically was created to cover only the simtrace project. We should rename this to osmocom-simcard at 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 at 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 at lists.osmocom.org instead? To differentiate: osmocom-event-orga at lists.osmocom.org should remain a private list related to organizational / administrative topics of those involved with organizing future events. == nextepc at lists.osmocom.org == Should have been renamed to open5gs at lists.osmocom.org quite some time ago, I simply forgot about it. My apologies. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Wed Mar 3 19:41:07 2021 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 3 Mar 2021 20:41:07 +0100 Subject: Osmocom Mailing List re-organization In-Reply-To: References: Message-ID: <20210303194107.GC1166@my.box> I think we also could change jenkins-notifications and/or gerrit-log, IIRC one of those was once named "the high noise mailing list" and catches more than just what the name says, currently don't remember which/both of them? builds@ ? noise@ ? build-noise@ ? From keith at rhizomatica.org Thu Mar 4 04:04:08 2021 From: keith at rhizomatica.org (Keith) Date: Wed, 3 Mar 2021 22:04:08 -0600 Subject: Osmocom Mailing List re-organization In-Reply-To: References: Message-ID: On 03/03/2021 03:00, Harald Welte wrote: > A re-organization of our major mailing lists. > > I would like to propose the following changes. Sounds good to me. Thanks for attending to this. Keith. From mychaela.falconia at gmail.com Mon Mar 8 08:00:06 2021 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 8 Mar 2021 00:00:06 -0800 Subject: Bringing back GrcardSIM2 Message-ID: Hello esteemed masters of Osmocom, (asking here because Harald's proposed osmocom-simcard list hasn't been created yet) I have some questions and experience-based corrections related to the gold nuggets contained in this wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2 First let me establish relevance: even though Sysmocom stopped selling these GR2 cards ages ago and it looks like the wider Osmocom community also stopped playing with them once sysmoUSIM-SJS1 came out, these same GrcardSIM2 cards are still available from Grcard in the present day. A week and a half ago I received 5 sample cards (plain white, no printing, unprogrammed) from Grcard that return the same ATR as is listed for sysmoSIM-GR2, and all of the card-model-specific proprietary commands described on the above wiki page work exactly the same on these cards as they once worked on sysmoSIM-GR2. I am now in the process of ordering a batch of 200 of these cards from Grcard, with my own custom printing applied (so they will look pretty, not plain white and not black like sysmoISIM-SJA2) - essentially I am bringing back an exact equivalent of the discontinued sysmoSIM-GR2. With relevance thus established, let's move on technical questions: * The wiki page describes a file named EF.WEKI, file ID 0001 under DF.GSM. Whoever wrote this wiki page, how did you get this fancy name EF.WEKI? Was there some kind of document from Grcard that described this card-model-specific proprietary file? Does that document still exist somewhere? Can there be some way for mere mortals like me to see that document? * The wiki page describes byte 3 of EF.WEKI as selecting COMP128 algorithm version. It lists 0 as selecting COMP128v1 and 1 as selecting COMP128v2, and these two codes are correct - confirmed by programming these codes, doing a RUN GSM ALGO command, and comparing returned SRES and Kc against osmo-auc-gen. However, the page lists 3 as selecting COMP128v3, and this part is not correct - writing 3 in there results in COMP128v2 being selected, just like code 1. Instead I need to write 2 into the lower nibble of this byte in order to get COMP128v3 SRES and Kc in response to RUN GSM ALGO. * The COMP128 selection code is just the lower nibble of byte 3 of EF.WEKI - the upper nibble is something else that currently eludes my understanding. The wiki page instructs users to write 0 into the upper nibble, and so does pySim-prog - yet in the initial "unprogrammed" state of the cards I received from Grcard, this upper nibble is set to 2, not 0. I could not see any observable difference in card behaviour whether the upper nibble is set to 0 or 2 - either way the lower nibble selects COMP128 version for RUN GSM ALGO operations. * The wiki page gives the impression that EF.WEKI is 19 bytes long in total. However, the actual size of this transparent EF on the card is 35 bytes, i.e., there is another 16-byte field (some other key?) after Ki. Of the people who were once privileged with proper official documentation for these cards, might anyone be able to tell what this other key is for? Could it perhaps be some kind of key for OTA? Before someone tells me that I should direct these questions to Grcard, given that I am buying cards from them, let me assure everyone that yes, of course I am doing everything I can to pry this information out of them. However, they seem to have the same attitude as most Chinese companies where they just want you to buy their product and not ask any technical questions, and whatever answers they do give are so terse that they feel like non-answers. But there is also the undeniable fact that once upon a time these cards were resold by Sysmocom, once upon a time this Osmocom community right here worked with these cards, and someone in this community (or on Sysmocom staff) must have gotten enough documentation to write the wiki page and pySim-prog support for them. Thus I feel at least somewhat justified in asking this community for help with bringing back this lost knowledge. On a happier note, my fc-pcsc-tools suite (fc-simtool and its limited- function companion fc-uicc-tool) is advancing quite a bit in functionality. I don't know how it compares to pysim-shell since I gave up trying to get the latter to run under Slackware (just too many difficult dependencies), but from what I read in mailing list posts, pysim-shell seems to be rather UICC-centric - I couldn't tell if it is supposed to work on non-UICC GSM 11.11 protocol cards or not. In contrast, my fc-simtool (written in C, zero dependencies beyond libpcsclite) speaks the classic GSM 11.11 SIM protocol and does everything that is possible within this protocol, including innovative hacks like brute force search of the file ID space. This tool should be ideal for cards like GrcardSIM2 which are non-UICC and for which the classic GSM 11.11 SIM protocol is native. The companion utility fc-uicc-tool for the UICC protocol is quite minimal in functionality, just enough to satisfy the few areas of curiosity I had in relation to that protocol and the cards I have around that speak it. These new C-language SIM tools live here: https://www.freecalypso.org/hg/fc-pcsc-tools/ The code is 100% my own original work and there is a LICENSE file at the top of the repository declaring it as public domain, so there should be no problem with Free Software status of the work. In hacking fellowship, Mother Mychaela From laforge at osmocom.org Mon Mar 8 13:15:31 2021 From: laforge at osmocom.org (Harald Welte) Date: Mon, 8 Mar 2021 14:15:31 +0100 Subject: Bringing back GrcardSIM2 In-Reply-To: References: Message-ID: Hi Mychaela, On Mon, Mar 08, 2021 at 12:00:06AM -0800, Mychaela Falconia wrote: > * The wiki page describes a file named EF.WEKI, file ID 0001 under > DF.GSM. Whoever wrote this wiki page, how did you get this fancy > name EF.WEKI? Was there some kind of document from Grcard that > described this card-model-specific proprietary file? Does that > document still exist somewhere? Can there be some way for mere > mortals like me to see that document? AFAICT there never was any documentation from GRcard, everything had to be reverse engineered from their proprietary windows programming software. When they at some point started to ship cards with pre-installed SIM toolkit applets that we never ordered, sysmocom ceased all contact with that supplier. > But there is also the undeniable > fact that once upon a time these cards were resold by Sysmocom, once > upon a time this Osmocom community right here worked with these cards, > and someone in this community (or on Sysmocom staff) must have gotten > enough documentation to write the wiki page and pySim-prog support for > them. See above. I'm not aware of anyone getting actual documentation. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rafael at riseup.net Mon Mar 8 13:35:14 2021 From: rafael at riseup.net (Rafael Diniz) Date: Mon, 8 Mar 2021 10:35:14 -0300 Subject: Osmocom Mailing List re-organization In-Reply-To: References:

Message-ID: Hi everybody, Just one question - we will be automatically subscribed on the new "openbsc" equivalent email list? Rafael On 3/4/21 1:04 AM, Keith wrote: > > On 03/03/2021 03:00, Harald Welte wrote: >> A re-organization of our major mailing lists. >> >> I would like to propose the following changes. > > Sounds good to me. Thanks for attending to this. > > Keith. > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ralph at schmid.xxx Mon Mar 8 13:44:27 2021 From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras) Date: Mon, 8 Mar 2021 14:44:27 +0100 Subject: Bringing back GrcardSIM2 In-Reply-To: References: Message-ID: <0d0b01d71421$284cd840$78e688c0$@schmid.xxx> Argh, now I know where I knew those cards from... GRSIMWrite 3.10, and the cheap Chinese cards. So I really had them, just not with Osmocom-label. I searched all places for the Osmocom cards, and the China cards just were in a box to my left. Ralph. > -----Original Message----- > From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of > Mychaela Falconia > Sent: Monday, March 8, 2021 9:00 AM > To: openbsc > Subject: Bringing back GrcardSIM2 > > Hello esteemed masters of Osmocom, > > (asking here because Harald's proposed osmocom-simcard list hasn't been > created yet) > > I have some questions and experience-based corrections related to the gold > nuggets contained in this wiki page: > > https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2 > > First let me establish relevance: even though Sysmocom stopped selling > these GR2 cards ages ago and it looks like the wider Osmocom community > also stopped playing with them once sysmoUSIM-SJS1 came out, these same > GrcardSIM2 cards are still available from Grcard in the present day. A week From mychaela.falconia at gmail.com Mon Mar 8 15:11:38 2021 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 8 Mar 2021 07:11:38 -0800 Subject: Bringing back GrcardSIM2 In-Reply-To: References: Message-ID: Hi Harald, > AFAICT there never was any documentation from GRcard, everything had to > be reverse engineered from their proprietary windows programming software. Aha, so instead of docs you got their proprietary sw. I never got the latter, but then I never asked them for it, as I was using the Osmocom wiki page and pySim code as my starting-point sources of knowledge. Now I need to ask Grcard for a copy of the same Winblows sw they gave you, so I can play with it, see what settings it allows to be programmed, and then see what it actually writes to the card. A couple of questions regarding this Grcard programming sw: * Do you know if WinXP is good enough for it, or if it needs something newer? I have an air-gapped WinXP machine which I set up a couple of years ago for similar purpose of knowledge extraction from proprietary sw - in that case the proprietary sw was TI CCS and the knowledge to be extracted was Calypso JTAG. * Does their sw work with USB CCID readers, or does it require a Phoenix-style serial reader instead? In either case, what drivers or other extra gunk does it require besides a bare Windows installation and Grcard sw itself? > When they at some point started to ship cards with pre-installed SIM > toolkit applets that we never ordered, sysmocom ceased all contact > with that supplier. Ouch! How did you discover the presence of those pre-installed STK applets, i.e., what was the visible symptom? Were the cards telling phones to add STK menus? So far I have tried inserting one of the sample cards I got into Mot C139 and Pirelli DP-L10 phones, both running their respective original firmwares, and on neither phone did I see anything STK-originating added to their menu structure. I have not yet tried inserting one of these cards into a board running UI- enabled FreeCalypso fw - I have tested a card in an FCDEV3B and proved it working (AT command modem), but I haven't tried the UI-enabled version yet. M~ From osmith at sysmocom.de Mon Mar 8 16:54:36 2021 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 8 Mar 2021 17:54:36 +0100 Subject: Jenkins: 2 new raspberry pi nodes / running on raspbian10 Message-ID: Hey all, short FYI regarding jenkins.osmocom.org: two new raspberry pi nodes are available, in order to reduce wait times for free build slots during heavy osmo-trx development. All three pis execute the jenkins jobs on top of raspbian10 now, unlike the old setup where it was on top of debian 9 in a LXC running in raspbian10. In other words, the LXC layer is gone now, and there might be slight differences related to debian9 vs. debian 10 packages. For all the jobs running in docker instead of directly on the host, there should be no difference at all. Details are in OS#5055. Best, Oliver -- - Oliver Smith https://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 osmocom.org Mon Mar 8 18:12:45 2021 From: laforge at osmocom.org (Harald Welte) Date: Mon, 8 Mar 2021 19:12:45 +0100 Subject: Osmocom Mailing List re-organization In-Reply-To: References:

Message-ID: Hi Rafael, On Mon, Mar 08, 2021 at 10:35:14AM -0300, Rafael Diniz wrote: > Just one question - we will be automatically subscribed on the new > "openbsc" equivalent email list? yes, I would simply rename the openbsc mailing list. There would also be aliases so mails to the old addresses (like openbsc at lists.osmocom.org) appear on the new list. It's not really an urgent topic, so I cannot specify when it will happen, but likely within the next 4-6 weeks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at osmocom.org Mon Mar 8 18:15:30 2021 From: laforge at osmocom.org (Harald Welte) Date: Mon, 8 Mar 2021 19:15:30 +0100 Subject: Bringing back GrcardSIM2 In-Reply-To: References:

Message-ID: Hi Mychaela, On Mon, Mar 08, 2021 at 07:11:38AM -0800, Mychaela Falconia wrote: > * Do you know if WinXP is good enough for it, or if it needs something > newer? I don't recall anything about it. But given that this was 2012, I'd assume XP would be sufficient. > * Does their sw work with USB CCID readers, or does it require a > Phoenix-style serial reader instead? no clue. It was a long time ago. > Ouch! How did you discover the presence of those pre-installed STK > applets, we noticed some Chinese-language pop-up message showing up on the display. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Mon Mar 8 19:26:36 2021 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Mon, 8 Mar 2021 11:26:36 -0800 Subject: Bringing back GrcardSIM2 In-Reply-To: References:

Message-ID: Hi Harald, > I don't recall anything about it. But given that this was 2012, I'd assume > XP would be sufficient. Thank you for the encouragement. I just found a copy of GRSIMWrite version 3.10 on the Internet (to those whom I emailed off-list asking for a copy, that request can now be scratched :), so I will try running it on that WinXP machine. > we noticed some Chinese-language pop-up message showing up on the display. Hmm, such visual observation seems to be only possible with a phone handset whose fw includes a Chinese font (how can a device display something in Chinese if it has no font for it), and AFAIK none of the Western-market classic GSM dumbphones I play with support Chinese characters. It looks like I will need to invest in a SIMtrace setup (hardware + learning curve) in order to truly confirm for sure what these cards do and don't do in terms of STK. Adding to my long to-do list. Now the big question in need of answering - just *why* am I messing with these Grcard SIMs instead of embracing the latest offerings from Sysmocom like the rest of this community? Two reasons: 1) As a general principle, I feel severe displeasure whenever something (anything really) that was available in the recent past gets discontinued and taken away. It is a well-known trait in human psychology, called loss aversion. Thus I see good moral value in bringing a discontinued product back from the grave just for its own sake, regardless of how poor that product may actually be. 2) Cost: this Grcard deal seems to be the only way to get programmable SIM cards in 2FF-only cut with a GSM-only file system (no USIM/ISIM) at an affordable price (a few hundred USD for 100 to 200 cards), without spending 3-4 kUSD on an MOQ-based custom order from The Premier Vendor. Spending 3-4 kUSD just on the SIM cards alone, on top of all other costs like BTS hardware and everything else, is simply not justifiable unless there is absolutely no other way. So I am trudging along... M~ From rafael at riseup.net Tue Mar 9 03:28:19 2021 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 9 Mar 2021 00:28:19 -0300 Subject: Osmocom Mailing List re-organization In-Reply-To: References:

Message-ID: <409d8ded-4b5a-01f4-99c4-7e1a9ae338b6@riseup.net> Just to know - tks Harald! On 3/8/21 3:12 PM, Harald Welte wrote: > Hi Rafael, > > On Mon, Mar 08, 2021 at 10:35:14AM -0300, Rafael Diniz wrote: >> Just one question - we will be automatically subscribed on the new >> "openbsc" equivalent email list? > > yes, I would simply rename the openbsc mailing list. There would also > be aliases so mails to the old addresses (like openbsc at lists.osmocom.org) > appear on the new list. > > It's not really an urgent topic, so I cannot specify when it will happen, > but likely within the next 4-6 weeks. > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From laforge at osmocom.org Tue Mar 9 19:47:44 2021 From: laforge at osmocom.org (Harald Welte) Date: Tue, 9 Mar 2021 20:47:44 +0100 Subject: Announcement of "OsmoDevCall" on March 12, 2021 In-Reply-To: References: Message-ID: Dear Osmocom community, It's my pleasure to announce the second OsmoDevCall at March 12, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This first meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: 2020 Osmocom review 20:45 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will summarize the major developments within Osmocom during the year 2020. Focus will be on the Osmocom CNI projects, but will also cover developments in other projects 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mychaela.falconia at gmail.com Wed Mar 10 22:22:31 2021 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Wed, 10 Mar 2021 14:22:31 -0800 Subject: sysmoISIM-SJA2 clock stop discrepancy Message-ID: Hello esteemed masters of Osmocom and Sysmocom, As I am doing some experiments with sysmoISIM-SJA2 cards in order to make a contingency plan in case I am not able to buy cards from Grcard beyond the 5 sample cards I got in February (my contact person there hasn't been responding to email for the past 3 days), I have noticed a discrepancy between this card's ATR and the file characteristics byte it returns in response to SELECT in the GSM 11.11 SIM protocol, regarding allowed levels for clock stop. My sysmoISIM-SJA2 cards (bought from the webshop in late Jan into early Feb) return the following ATR: 3B 9F 96 80 1F 87 80 31 E0 73 FE 21 1B 67 4A 4C 75 30 34 05 4B A9 The TA byte for T=15 indicates allowed voltage classes and allowed levels for clock stop. On this card this byte equals 0x87, meaning all 3 voltage classes (good), but also indicating that when the clock is stopped, it should be HIGH. However, the file characteristics byte returned in response to SELECT (both MF and DF_GSM) in the GSM 11.11 SIM protocol is 0xB1; decoding this byte per 3GPP TS 51.011, it says "clock stop allowed, no preferred level". Thus the file characteristics byte says that there is no preferred level, yet ATR says that HIGH level is preferred - or not just preferred, but required? (7816-3 seems to say it is only a preference, not a requirement; I seem to recall some other spec that said it's a requirement, but I can't find it now.) This discrepancy poses a potential problem if these cards are to be used in classic GSM/2G dumbphones whose original firmwares are based on the reference from TI. That reference fw code does not look at ATR for the purpose of determining allowed clock stop levels (most classic SIMs didn't have that T=15 TA byte in their ATR, it became commonly present when UICC/USIM stuff came along), instead it looks at the file characteristics byte returned in response to SELECT of DF_GSM. Furthermore, if the file characteristics byte says that there is no preferred level for clock stop, TI's reference fw configures the hw to leave the clock LOW during idle. I can only reason that other classic dumbphone firmwares (from other chip vendors) may very likely do the same: GSM SIM specs (11.11 and 51.011) don't require ME implementations to look at T=15 bytes in ATR, instead they direct MEs to follow the file characteristics byte. Can someone from Sysmocom officially confirm whether or not it is OK to operate sysmoISIM-SJA2 cards with clock stop at LOW level, contrary to ATR asking it to be HIGH? I have done a limited test of putting one of these cards into an FCDEV3B (with this aspect of the firmware left unmodified, so the clock line was low during idle) and the SIM interface appeared to still be alive after some deep sleep (clock stop) cycles. However, it was a very limited test, and I don't have my own network set up yet to make a more thorough test - and in any case, an official confirmation would be much better than anecdotal observations. TIA, Mychaela From bjoern.riemer at fokus.fraunhofer.de Wed Mar 17 08:56:35 2021 From: bjoern.riemer at fokus.fraunhofer.de (=?iso-8859-1?Q?Riemer=2C_Bj=F6rn?=) Date: Wed, 17 Mar 2021 08:56:35 +0000 Subject: where to send pySim patches Message-ID: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de> Hello list, we are working on extensions to pySim for the sjs2 card mainly to make our 5G phones to accept our network. How should we send this patches? Via this mailing list or should we wait a little longer until Harald finished restructuring the mailing lists? Best Regards Bjoern -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyanitskiy at sysmocom.de Wed Mar 17 13:22:19 2021 From: vyanitskiy at sysmocom.de (Vadim Yanitskiy) Date: Wed, 17 Mar 2021 14:22:19 +0100 Subject: where to send pySim patches In-Reply-To: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de> References: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de> Message-ID: Hello, On 3/17/21 9:56 AM, Riemer, Bj?rn wrote: > How should we send this patches? we do accept patches via Gerrit, please see: https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit/ Best regards, Vadim. -- - Vadim Yanitskiy 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 osmocom.org Wed Mar 17 16:11:14 2021 From: laforge at osmocom.org (Harald Welte) Date: Wed, 17 Mar 2021 17:11:14 +0100 Subject: where to send pySim patches In-Reply-To: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de> References: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de> Message-ID: Hi Bjoern, On Wed, Mar 17, 2021 at 08:56:35AM +0000, Riemer, Bj?rn wrote: > we are working on extensions to pySim for the sjs2 card mainly to make our 5G phones to accept our network. excellent. I presume it mostly relates to either disabling some EF.UST entries related to 5G, or filling those files in DF_5GS with content? > How should we send this patches? We are using a gerrit-based patch submission process, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit and https://gerrit.osmocom.org/q/project:pysim gerrit is integrated with jenkins, wehre a build slave will execute automatic tests with a variety of different physical SIM cards. Only if those pass, you get a V+1. And we perform code review/voting in the gerrit, too. > Via this mailing list or should we wait a little longer until Harald finished restructuring the mailing lists? I would prefer to submit via gerrit. If you face some difficulties, we can fall back to the mailing list, but then somebody will have to pick the patches up from the ML and push them in gerrit anyway, as all our commits go through gerrit for automatic testing and approvals. Thanks, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bjoern.riemer at fokus.fraunhofer.de Wed Mar 17 20:48:54 2021 From: bjoern.riemer at fokus.fraunhofer.de (=?iso-8859-1?Q?Riemer=2C_Bj=F6rn?=) Date: Wed, 17 Mar 2021 20:48:54 +0000 Subject: AW: where to send pySim patches In-Reply-To: References: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de>, Message-ID: Hi Harald, Von: Harald Welte Gesendet: Mittwoch, 17. M?rz 2021 17:11 > excellent.? I presume it mostly relates to either disabling some EF.UST entries related to 5G, or filling > those files in DF_5GS with content? Currently we are flippng some bits in the EF*plmnwACT lists and adding additional entries in the ehplmn list. It seems that one specific baseband vendor needs the current HPLMN in the eHPLMN list as well.. We might have a look at the other files as well, but for now testing is not so fast as we have very limited access to the offices where the gNodeB is located.. > gerrit is integrated with jenkins, wehre a build slave will execute > automatic tests with a variety of different physical SIM cards. Does this mean that if we introduce layout and content changes to the pySim-read output we have to modify the files in the pysim-testdata subfolder as well? Bjoern From laforge at gnumonks.org Thu Mar 18 08:51:55 2021 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Mar 2021 09:51:55 +0100 Subject: where to send pySim patches In-Reply-To: References: <619e9039b22a431ead2a3372d603eb10@fokus.fraunhofer.de>, Message-ID: On March 17, 2021 9:48:54 PM GMT+01:00, "Riemer, Bj?rn" wrote: >> gerrit is integrated with jenkins, wehre a build slave will execute >> automatic tests with a variety of different physical SIM cards. > >Does this mean that if we introduce layout and content changes to the >pySim-read output we have to >modify the files in the pysim-testdata subfolder as well? Yes, you will see the patches failing otherwise. You can re-upload any number of times until it passes. Please not in general I would encourage most new features, particularly for supporting new file types to be primarily developed for pysim-shell. But let's first have your patches in gerrit and review them there. Thanks! -- Sent from a mobile device. Please excuse my brevity. From laforge at osmocom.org Thu Mar 25 17:43:32 2021 From: laforge at osmocom.org (Harald Welte) Date: Thu, 25 Mar 2021 18:43:32 +0100 Subject: Announcement of "OsmoDevCall" on March 26, 2021 In-Reply-To: References: Message-ID: Dear Osmocom community, It's my pleasure to announce the second OsmoDevCall at March 26, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This first meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: multi-TRX + frequency hopping in OsmoBTS 20:45 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will present the relatively recent introduction for the support of baseband frequency hopping in multi-TRX OsmoBTS. 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From morteza.ali.ahmadi at gmail.com Fri Mar 26 15:19:37 2021 From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi) Date: Fri, 26 Mar 2021 19:49:37 +0430 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. Message-ID: Hi, osmocom team members. In order to have an internet connection in UE, we have run OsmoGGSN project to set up GGSN. Also, SGSN is developed in our system. At this step, UE connects to our network core and we can query to an arbitrary site in the UE browser and we see the answer of the query without any problem and everything is OK. But after about 30 or 40 seconds, UE sends "Deactivate PDP Context Request" with SM Cause "SM Cause: Protocol error, unspecified (111)" and the connection is reset and a new "Activate PDP Context Request" is required. What is the reason and how can we solve it? -- *When there is much light, The shadow is deep...* -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at osmocom.org Fri Mar 26 18:49:51 2021 From: laforge at osmocom.org (Harald Welte) Date: Fri, 26 Mar 2021 19:49:51 +0100 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. In-Reply-To: References: Message-ID: Hi, On Fri, Mar 26, 2021 at 07:49:37PM +0430, morteza ali Ahmadi wrote: > In order to have an internet connection in UE, we have run OsmoGGSN project > to set up GGSN. Also, SGSN is developed in our system. So you are seeing a problem between your custom, non open source SGSN and the UE, but you ask here on the Osmocom list for assistance? If I'm correct, then the following holds true: As we don't have access to your custom SGSN, only you can investigate and resolve that ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From morteza.ali.ahmadi at gmail.com Fri Mar 26 19:01:31 2021 From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi) Date: Fri, 26 Mar 2021 23:31:31 +0430 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. In-Reply-To: References: Message-ID: Thanks, so can you tell us about the reason of this error? Is this error is related to "Activate PDP Context Accept" and its parameters or something else? On Friday, March 26, 2021, Harald Welte wrote: > Hi, > > On Fri, Mar 26, 2021 at 07:49:37PM +0430, morteza ali Ahmadi wrote: > > In order to have an internet connection in UE, we have run OsmoGGSN > project > > to set up GGSN. Also, SGSN is developed in our system. > > So you are seeing a problem between your custom, non open source SGSN and > the UE, > but you ask here on the Osmocom list for assistance? If I'm correct, then > the following holds true: As we don't have access to your > custom SGSN, only you can investigate and resolve that ;) > > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- *When there is much light, The shadow is deep...* -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Mar 26 19:50:37 2021 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 26 Mar 2021 20:50:37 +0100 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. In-Reply-To: References:

Message-ID: Hi again, On Fri, Mar 26, 2021 at 11:31:31PM +0430, morteza ali Ahmadi wrote: > Thanks, so can you tell us about the reason of this error? Is this error is > related to "Activate PDP Context Accept" and its parameters or something > else? how will the discussion of fixing problems that appear to happen between the UE and your proprietary SGSN be of benefit to the Osmocom developers and/or users? This list is about open source mobile communications. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From morteza.ali.ahmadi at gmail.com Fri Mar 26 20:06:09 2021 From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi) Date: Sat, 27 Mar 2021 00:36:09 +0430 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. In-Reply-To: References:

Message-ID: We asked this question here, because we set the content of "Create PDP Context Request" (from SGSN to GGSN) and "Activate PDP Context Accept" (from SGSN to HNB to UE) and "RAB-Assignment Request" (from SGSN to HNB) based on the generated packets in osmocom logs and the occured problem may be related to the parameters in these packets, specially "Activate PDP Context Accept". On Saturday, March 27, 2021, Harald Welte wrote: > Hi again, > > On Fri, Mar 26, 2021 at 11:31:31PM +0430, morteza ali Ahmadi wrote: > > Thanks, so can you tell us about the reason of this error? Is this error > is > > related to "Activate PDP Context Accept" and its parameters or something > > else? > > how will the discussion of fixing problems that appear to happen > between the UE and your proprietary SGSN be of benefit to the Osmocom > developers and/or users? This list is about open source mobile > communications. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- *When there is much light, The shadow is deep...* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mychaela.falconia at gmail.com Fri Mar 26 20:37:33 2021 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 26 Mar 2021 12:37:33 -0800 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. In-Reply-To: References:

Message-ID: Hi Morteza, This may be a silly question, but my most immediate and most natural reaction to your inquiry is a little different from Harald's. Harald's response focuses on the notion that FLOSS communities like Osmocom should not be helping proprietary software developers/users, but I see an even more fundamental question in need of answering: just *why* are you implementing your own SGSN, as opposed to using already existing OsmoSGSN+OsmoHNBGW? If you consider the existing Osmocom implementation to be poor and prefer to write your own alternative mostly from scratch (I am often guilty of the exact same behaviour: I just wrote from scratch my own suite of tools for programming SIM cards instead of improving Osmocom community's existing pySim tools), then why are you not releasing your own alternative version as Published Source Software? Perhaps I missed it, but I never saw you post a link to the source for your alternative SGSN. Just trying to understand, Mother Mychaela P.S. Published Source Software (PSS) is my preferred term for ALL software whose source code is freely published on the Internet by the authors or maintainers of the sw in question, regardless of whether it is under a free license or not - thus it is a more expansive category than FLOSS. FLOSS is a proper subset of PSS.