- OpenBSC - lists.osmocom.org

Osmocom CNI release 202102

by Pau Espin Pedrol

Dear all, I am pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. Find more information about the release here [1]. Osmocom "Latest" repositories in OBS [2] should already contain packages for the new versions. OpenEmbedded related meta-layers such as meta-telephony usual stable/testing branch "201705" [3] have also been updated to build recipes for new versions. Regards, Pau [1] https://osmocom.org/news/132 [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [3] https://git.osmocom.org/meta-telephony/log/?h=201705 -- - Pau Espin Pedrol <pespin(a)sysmocom.de> 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

3 years, 2 months

1
0
0 0

Looking for historical sysmoSIM-GR2 card

by Mychaela Falconia

Hello fellow GSM hackers, Would anyone here happen to have a sysmoSIM-GR2 card (once sold by Sysmocom aeons ago, but long since discontinued) which they would be willing to sell? I have a friend who has sysmoSIM-GR1 and sysmoUSIM-GR1 (other long-discontinued historical cards from aeons ago), but no sysmoSIM-GR2. I am looking for just one card (doesn't matter if it is fully intact, broken out 2FF, or even cut down to 3FF), and I am willing to pay premium price for it, plus I will pay for private courier shipping to bypass USPS which can't be trusted with anything valuable these days. So if anyone has one of these cards which they would be willing to part with, and could use a little money, please give me a holler. Oh, and if the card's SUPER ADM PIN has been changed to something other than the default 88888888, I will need to be given that key. Background info: I am trying to get some new cards from Grcard, and I ordered samples. These samples were originally scheduled to arrive in USA next week, but then some snafu happened, and the shipment got returned to the sender. I was given a non-answer as to what the problem issue is, and I basically have to wait an indefinitely long time (at least past LNY 2-week holiday, plus however much longer after that) to get a resent package - and it looks like they are going to resend via a slower method too. Meanwhile I have implemented Grcard2 custom commands in fc-simtool based on this wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2 I am now looking for a way to test my Grcard2 command implementation against some card that is *known* to speak Grcard2 protocol and not some other (hence sysmoSIM-GR2 would be ideal), and when I receive the new sample cards from Grcard at some future time (probably many weeks or even months out), I will be able to compare, and determine if they are also Grcard2 or something else. (If the new cards turn out to be different from both Grcard1 and Grcard2, I will call them Grcard3. :) Hopeful, Mother Mychaela of FreeCalypso

3 years, 2 months

3
3
0 0

OTA RFM on sysmoISIM-SJA2 cards

by Mychaela Falconia

Hello Osmocom community, Has anyone here ever played with the RFM (Remote File Management) feature on sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards? I know that a lot of people play with RAM (Remote Application Management) for installing Java applets, but I am more interested in RFM for doing a different kind of OTA programming - I am seeking to recreate the workflow of traditional GSM network operators where "blank" (not yet activated, but ready to activate) SIM cards sit on store shelves with their IMSI and secret keys (Ki/K/OPc etc) already programmed at the factory, but blank EF_MSISDN because the future user's phone number is not known yet. Customers activate these SIMs by reading the ICCID from the card to customer service over the phone, or salespeople in stores scan the ICCID barcode - and then the operator's customer management system matches that ICCID with its knowledge of the IMSI and secret keys, and the service gets activated on the new SIM. And then the operator's network uses SMS-PP SIM data download to program the EF_MSISDN record in the newly activated SIM - I know full well that a phone does not need to know its own MSISDN to make and receive calls, but every classic GSM dumbphone has a menu command for "Show my number" or whatever it's called, this command displays the MSISDN record from the SIM, and traditional operators program this record OTA so that this menu command will work. I am seeking to recreate this OTA programming step. I just got the needed KI[CD][23] OTA keys for my sysmoUSIM-SJS1 cards (thanks Sysmocom support!), and I am able to exercise RFM successfully on these cards by uncommenting these lines in the shadysim.py script: # for RFM testing ac.test_rfm() exit(0) It appears that the "tribal" knowledge (not written in any formal document, AFAICT) of how to use the RFM feature on sysmoUSIM-SJS1 cards exists only in the following code stanzas in shadysim.py, code that never executes unless you uncomment that ac.test_rfm() call: def send_wrapped_apdu_rfm_sim(self, data): # TAR RFM SIM: B00010, sysmoSIM SJS1: MSL = 6, second keyset return self.send_wrapped_apdu_internal(data, 'B00010', 6, 2, 2) def send_wrapped_apdu_rfm_usim(self, data): # TAR RFM USIM: B00011, sysmoSIM SJS1: MSL = 6, third keyset return self.send_wrapped_apdu_internal(data, 'B00011', 6, 3, 3) It was only thanks to the above code lines and comments that I learned that I need to use keyset 2 for SIM RFM, and how else would we know the needed magic TAR if not for the above code and comments? In any case, the RFM test function of shadysim.py works like a charm on my sysmoUSIM-SJS1 cards with the right keys (successfully displays the IMSI read out via RFM), and I am now going to work on my own C code that will replace Python and do what I need. However, I also tried the exact same shadysim.py RFM test function on the newer sysmoISIM-SJA2 cards, and it does NOT work. I run the exact same shadysim.py (modified only to uncomment the RFM test) that works against sysmoUSIM-SJS1, but when I run it against sysmoISIM-SJA2 and specify the respective card's KIC2 and KID2 from the webshop key data email, I get this output: ICCID: 8988211000000471501f ('', '') Here is the output with a good sysmoUSIM-SJS1: ICCID: 8988211000000386808f ('089910070000306808', '9000') Given that the code stays exactly the same and I am merely specifying different keys as needed for each card, there must be something different about the new sysmoISIM-SJA2 cards with respect to RFM. Perhaps the TAR is different? Perhaps the association of which keyset goes for what is different? Some other differences like different crypto algorithms being used? Perhaps a migration from 3DES to AES? I am fine with just using sysmoUSIM-SJS1 for development of my C tools (tools which will hopefully be extended later to work with other vendors' SIMs beyond just Sysmocom), but it would be nice to fill in the knowledge gap regarding sysmoISIM-SJA2 and get these cards to work as well. In hacking fellowship, Mother Mychaela

3 years, 2 months

2
3
0 0

Introducing ntt. Modern tools for TTCN-3

by Simon, Matthias (Nokia - DE/Ulm)

Hi, I am Matthias, a TTCN-3 tool developer from Nokia. Thank you for opening your work. Your repository osmo-ttcn3-hacks helped me to understand how other developers use TTCN-3 for testing. This gave me valuable insights for tool development. I hope I can give something back by opening up our internal TTCN-3 tools as well. Harald suggested to introduce them on this list. I'd appreciate your feedback. Our project is called ntt and it provides various tools for working with TTCN-3 [1]. For example, you can create a tags file: $ ntt tags ./osmo-ttcn3-hacks/bts >TAGS Or you can list things. To filter cyclic imports, for example: $ ntt list imports ./osmo-ttcn3-hacks/bts | tsort 1>/dev/null But the most interesting piece is probably the TTCN-3 language server: ntt implements the language server protocol. This makes ntt a universal TTCN-3 language plugin for virtually any editor or IDE [2]. It's still very much beta, but we are finishing the Go to Definition feature (as replacement for ctags files). The next feature would be adding various diagnostics. It would be great if you could give ntt a try and share your experience or editor configuration with me. This is my first open source project and we still have to figure some stuff out. So please excuse if there are still some rough edges. Cheers, Matthias [1] https://nokia.github.io/ntt/ [2] https://nokia.github.io/ntt/editors/

3 years, 2 months

3
4
0 0

RFC: generic CTRL interface for VTY config settings

by Harald Welte

Dear all, we always had said the VTY is a human CLI, while the CTRL interface is for interfacing with other software. This was primarily related to asking users to not parse the VTY output of "show" commands or the like. For configuration via VTY, we have to provide a stable interface anyway, as otherwise loading config files would not be possible across [non-major] software upgrades. While that is right in principle, the fact that we don't have a generic configuration store / API / MIB means that one would explicitly have to add CTRL command for all relevant settings, which may have been realistic in 2010, but is unrealistic with the hundreds of VTY configuration parameters today. I was thinking wither it might make sense to add a generic CTRL interface GET/SET for "configuration" mode VTY settings. This would mean we write code once, and immediately expose all our VTY nodes to CTRL. Thinking of the following example done via VTY: ----------------------------------- OsmoBSC> enable OsmoBSC# configure terminal OsmoBSC(config)# network OsmoBSC(config-net)# bts 0 OsmoBSC(config-net-bts)# trx 1 OsmoBSC(config-net-bts-trx)# timeslot 0 OsmoBSC(config-net-bts-trx-ts)# training_sequence_code 3 ----------------------------------- We could have something like the following CTRL command: SET network.bts.0.trx.1.timeslot.0.training_sequence_code 3 The devil is a bit in the details of the syntax * the normal '.' as separator looks generally OK, I think we have [almost?] no VTY commands that include a ',' * we somehow need some kind of separator to tell where individual VTY commands are separated, like SET network."bts 0"."trx 1"."timeslot 0".training_sequence_code 3 or SET network|bts.0|trx.1|timeslot.0|training_sequence_code 3 or SET network#bts.0#trx.1#timeslot.0#training_sequence_code 3 or SET network.bts#0.trx#1.timeslot#0.training_sequence_code 3 SET network.bts@0.trx@1.timeslot@0.training_sequence_code 3 I think the last examples would be more "natural" for existing CTRL interface code, as the dot separat separates tokens, and we simply expand the '#' or '@' to spaces in the context of VTY commands The generic vty-cfg-via-CTRL code then would basically emulate a user entering the sequence of commands - including the "exclusion" of not allowing multiple concurrent VTY or vty-cfg-via-CTRL users at the same time What do you guys think? Regards, Harald -- - 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)

3 years, 2 months

5
7
0 0

testing TTCN3 test stability

by Harald Welte

I think this might be of interest to some of the other developers. Soemtimes we have a problem that the test suite itself is not 100% stable, and it's not easy to reproduce a test that fails sporadically every Nth time. As the "execute" statement in the "control" section actually returns a verdict type, you can use the following construct in a control section: control { for (var integer i := 0; i < 10000; i := i+1) { var verdicttype v; v := execute( TC_paging_ps_ptp_lac() ); if (v != pass) { break; } } } This way you keep running the test suite until the given test fails for the first time. Then go do something else for some hour(s) and by the time you get back, hopefully you will have reproduced the problem. Regards, Harald -- - 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)

3 years, 3 months

2
2
0 0

Inexpensive Huawei GSM Picocells

by Saturn Rocket

3 years, 3 months

4
6
0 0

Question about OsmoGGSN project

by morteza ali Ahmadi

Hi, osmocom team members We have run OsmoGGSN project using the attached config file in this email and the following command: osmo-ggsn As you can see in the config file, we have set IP 127.0.0.2 for GGSN. After executing the above command, a tunnel named tun4 is created. To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow: sgsnemu -l 127.0.0.1 -r 127.0.0.2 After executing the above command, we see that 2 packets are sent from SGSN to GGSN. These packets are "Echo request" and "Create PDP context request" and GGSN responses to SGSN with the packets "Echo response" and "Create PDP context response". To test tun4, we send a GTP <DNS> packet containing an arbitrary query to GGSN and we see that this GTP <DNS> packet is received in Loopback (lo) interface and also, the DNS packet is received in tun4 interface. But there is no DNS response to our query neither in tun4 interface nor lo interface. A screenshot of the lo interface and tun4 interface in the wireshark is attached in this email (right is lo and left is tun4). How can we receive DNS responses to our DNS query? (Does tun4 require routing or something else?) -- *When there is much light, The shadow is deep...*

3 years, 3 months

2
2
0 0

Ettus USRP E100 usage for current osmo-trx

by Ivan Babanov

Hello all! Does anybody have any actual information about the possibility to run osmo-trx on Ettus E100 board? I see some references in manuals about the possibility of running it, but I can't find details on how to do it. I tried several ways: 1. Build from source on target HW. Unfortunately "autoreconf" crashes with some perl module dependency. 2. Install binaries. Binaries for arm available only for Debian 9, so I built an image and installed Debian 9.0 on SD-card. Installation of binaries was unsuccessful because of some unmet dependencies. 3. Build from scratch on Debian 9.0. I was partially successful in it. I was able to build osmocore and osmo-trx. The problem was to run it because now, uhd_find_devices shows an empty list. It looks like that kernel module usrp_e.ko should be loaded, but I have no idea where to find its sources. And one more question: Is it a proper place to ask questions related to BTS and TRX? Should I move my question to some other mail list? Thank you Ivan

3 years, 3 months

2
1
0 0

OsmoHNBGW M3UA IPSP mode

by Mirko Kovacevic

Hello, not many discussions found on OsmoHNBGW topic. 1. Can we connect O' HNBGW directly to SGSN without STP (IPSP mode)? 2. If not, I am wondering do OSMOCOM have development support for IPSP M3UA mode in SIGTRAN development files or elsewhere? Thank you in advance, and keep shaking mobile development world. Mirko K.

3 years, 3 months

2
1
0 0

SMPP Alert Notifications

by Keith

Hi Osmocom Community. I'd like to extend the SMPP protocol alert notifications to be able to differentiate between IMSI_ATTACH, NORMAL and PERIODIC LURs The reason is to be able to react to an initial attach by sending a "Welcome" SMS. SMPP specifies only three status possibilities: 0 = Available 1 = Disabled 2 = Not Available (Detaching) I've added 3 for IMSI_ATTACH - Actually I ended up using != PERIODIC because not all phones send an ATTACH after a DETACH, some send NORMAL LUR. With this the ESME can respond to an alert notification that has status 3 by looking up the IMSI to see if it's known/autorised etc (this is outside of osmo-hlr in my use case, although I guess it could also be done by checking what the HLR says inside the MSC) Anyway.. I'm wondering if anybody else ever did this, and do we want/accept this functionality in master osmo-msc? Or.. any better ideas on how to do it? Thanks k/

3 years, 4 months

2
1
0 0

OsmoBSC - SCCP Connection to Nokia MSC

by Sonny Lafuente

Hi Community, Happy New Year! Would like to ask if anyone here have experience integrating OsmoBSC to Nokia MSC? Currently we are doing the integration in Nokia MSC and we encountered issue. Basically, in the SCCP part, the BSC is trying to send UDT (BSSAP) Reset but no response from the MSC. After the default timer of the RESET, we observed a SACK SST and SACK UDTS. In the SACK SST, we saw the trace that there is no Calling indicator which is my BSC point code. When checking the trace we saw this Affected Subsystem Number: 254. I’ve red some documentations in OSMO but I don’t find any SCCP management configuration in OSMO so I think this one is on MSC side. Below is the Trace we captured. BSC Point code - 2262 Nokia Point code - 7039 Regards, Sonny

3 years, 4 months

1
1
0 0

set a c/c++ standard for all osmocom core network projects

by Alexander 'lynxis' Couzens

Hi, I would like to start a discussion to set for all osmocom core network projects a language standard (could be also set for other osmocom projects). The current state is the code is compiled with the compilers choice of c/c++. This produce unexpected build failures on newer or older system. I would like to start setting it to c11/c++11 + gnu extensions. This is a more random choice of standard. I would argue to have at least c99 for c. Any feedback? Best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

3 years, 4 months

2
1
0 0

OsmoBSC(config-net-bts) cell reselection parameters dont show up after set up

by Mario Lucas

Dear Team please help me with the following question: I want to set up following parameters in osmobsc config: cell bar quality cell reselection offset temporary offset penalty time cell reselection hysterisis These parameter play role when a MS should reselect another cell. These parameters do appear in OsmoBSC(config-net-bts) and i do set up them. But when i run «show running-config» only hysterisis is present… the rest have gone …. also gsmtap from wireshark does not show the rest of parameters. Pls help if you can …. Pls find the log from OsmoBSC(config-net-bts)# show running-config: OsmoBSC(config-net-bts)# show running-config Current configuration: ! ! log stderr logging filter all 1 logging color 0 logging print category-hex 1 logging print category 0 logging timestamp 0 logging print file 1 logging level rll notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level pag notice logging level meas notice logging level msc notice logging level ho notice logging level hodec notice logging level ref notice logging level nat notice logging level ctrl notice logging level filter debug logging level pcu debug logging level lcls notice logging level chan notice logging level ts notice logging level as notice logging level cbs notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice logging level ljibuf notice logging level lrspro notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive cs7 instance 0 point-code 0.23.3 network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 dyn_ts_allow_tch_f 0 bts 0 type sysmobts band GSM900 cell_identity 6969 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-description attach 1 channel-description bs-pa-mfrms 5 channel-description bs-ag-blks-res 1 no access-control-class-ramping access-control-class-ramping-step-interval dynamic access-control-class-ramping-step-size 1 early-classmark-sending forbidden early-classmark-sending-3g allowed ipa unit-id 6969 0 oml ipa stream-id 255 line 0 neighbor-list mode automatic codec-support fr amr tch-f modes 0 2 4 7 amr tch-f threshold ms 32 32 32 amr tch-f hysteresis ms 8 8 8 amr tch-f threshold bts 32 32 32 amr tch-f hysteresis bts 8 8 8 amr tch-f start-mode auto amr tch-h modes 0 2 4 amr tch-h threshold ms 32 32 amr tch-h hysteresis ms 8 8 amr tch-h threshold bts 32 32 amr tch-h hysteresis bts 8 8 amr tch-h start-mode auto gprs mode none trx 0 rf_locked 0 arfcn 10 nominal power 26 max_power_red 16 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 msc 0 ip.access rtp-base 4000 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text codec-list fr1 hr1 fr2 fr3 hr3 type normal allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden amr-payload octet-aligned asp-protocol m3ua lcls-mode disabled lcls-codec-mismatch forbidden mgw local-port 2727 mgw remote-ip 127.0.0.1 mgw remote-port 2427 bsc mid-call-timeout 0 no missing-msc-text cbc no remote-ip no listen-port end OsmoBSC(config-net-bts)# -- Mario Lucas

3 years, 5 months

4
3
0 0

Eclipse TITAN / warnings / finding errors in the log

by Harald Welte

Hi! It has recently come to my attention that people find it hard to find error messages when compiling TTCN-3 code. This is primarily due to the hundreds to thousands of compiler warnings which [at least our] code generates when building with ttcn3_compiler of TITAN. While some of those warnings indeed should be resolved, a great number of them is actually things where we know what we are doing, and where we'd normally want to disable the warnings. Unfortunately, TITAN doesn't have a system to selectively disable warnings like -Wno-foo in gcc. There are two things that help: 1) colorized output of ttcn3_compiler, which is something I submitted quite a long time ago, but which hasn't e.g. ended up yet in a number of distribution packages. Please feel free to use the eclipse-titan package we build in the OBS network:osmocom:latest feeds to get that feature 2) ttcn3_compiler actually has a '-w' command line argument to make all warnings quiet, which is also supported by ttcn3_makefilegen. You can edit the osmo-ttcn3-hacks/regen-makefile.sh to add that option to ttcn3_makefilegen 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)

3 years, 5 months

2
1
0 0

trx output power config in bts

by Mario Lucas

Dear team could you pls help me with this question In bts config we have following entries: trx 0 nominal power 23 ! to use full TRX power, set max_power_red 0 max_power_red 20 and osmotrx tx-attenuation (oml|<0-50>) So why do we need these «max_power_red 20» and «osmotrx tx-attenuation» which both as i understand weaken the signal? If we want to have a weak signal why we just don’t use only «nominal power» with whatever weak or strong signal value we want? Thank you so much -- Mario Lucas

3 years, 5 months

2
1
0 0

Openbsc install limenet sdr

by Choukou Moun

Hello, Anybody have success to install openbsc on limenet sdr? I have many compilation error with sources or packages. Thank you.

3 years, 5 months

2
4
0 0

Unable to send OTA updates to SIM

by bryan coxwell

The setup: - I am using Osmo-MSC, Osmo-HLR, python-smpplib, and sim-tools. My SIM card is a Sysmocom USIM-SJS1 which came with OTA keys. - Osmo-MSC has been configured to accept SMPP connections, and dcs-transparent has been set. - Using sim-tools with the --smpp flag, I generated the necessary SMPP messages to load the HelloSTK.cap file to the SIM. (Essentially, I've followed the instructions here: https://osmocom.org/projects/cellular-infrastructure/wiki/Shadysimpy) - Sim-tools outputs 6 messages, so in a separate program I use python-smpplib to push each message to the MSC over SMPP. - The send function in my program looks like this: parts = ["027000003815060115150000001dbf31df8eb85248617ff79260f7bf0abd332e2b3c> "02700000901506011515000000d85420f0f778e35b4b8e0ae5d961593444f20fdebb> "02700000901506011515000000729062e3cc920acc51be4f22fd067314bfaee313d6> "02700000901506011515000000373f30a3c12b494d3089c70a2dd46e33e3fccac790> "0270000068150601151500000083f04c39ef2df571bd5389f71b8c528e9b3edea046> "02700000601506011515000000ad6eeebc9373de8bd3a8888324ffaad4d8cd935f0c> ] for part in parts: pdu = client.send_message( source_addr_ton=smpplib.consts.SMPP_TON_INTL, source_addr='0', dest_addr_ton=smpplib.consts.SMPP_TON_INTL, destination_addr='3331112222', short_message=bytes.fromhex(part), data_coding=246, esm_class=64, registered_delivery=True, ) print(pdu.sequence) I have Wireshark running on the computer hosting the MSC, and it shows GSM SMS messages sending to the UE, however there is no response, and when I inspect the SIM card, no applet has been loaded. Am I missing something here? What could be causing this issue? Thanks!

3 years, 5 months

1
0
0 0

Re: Help on using pysim to flash a SIM card

by Chunlin Yang

Hi Vadim and all, pyProg.py fails with an error, could you help (btw, I change all real info to xxx :)): support@S2600WFT:~/pysim$ python ./pySim-prog.py -p 0 -x 208 -y 93 -t sysmoUSIM-SJS1 -i 208930000000003 --op=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -k xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -s xxxxxxxxxxxxxxxxxxxxx -a xxxxxxxx Using PC/SC reader interface Ready for Programming: Insert card now (or CTRL-C to cancel) Generated card parameters : > Name : Magic > SMSP : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > ICCID : xxxxxxxxxxxxxxxxxxxx > MCC/MNC : 208/93 > IMSI : xxxxxxxxxxxxxxx > Ki : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > OPC : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > ACC : None > ADM1(hex): xxxxxxxxxxxxxxxx Programming ... Card programming failed with an execption: ---------------------8<--------------------- Traceback (most recent call last): File "./pySim-prog.py", line 719, in <module> rc = process_card(opts, first, card_handler) File "./pySim-prog.py", line 671, in process_card card.program(cp) File "/home/support/pysim/pySim/cards.py", line 713, in program self._scc.verify_chv(0x0A, h2b(p['pin_adm'])) File "/home/support/pysim/pySim/commands.py", line 206, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc) File "/home/support/pysim/pySim/transport/__init__.py", line 104, in send_apdu_checksw raise RuntimeError("SW match failed! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed! Expected 9000 and got 63c9. ---------------------8<--------------------- Programming failed: Remove card from reader Thanks. Br, Andrew On Tue, Dec 1, 2020 at 1:07 AM Chunlin Yang <chliny2016(a)gmail.com> wrote: > Thanks a lot Vadim! > I have thought it might be an issue between python3 and python2. So I have > tried on both versions. > on Python3, I got same error. > But now with this command 'python ./pySim-read.py -p0', it works. I used > to use this command './pySim-read.py -p0' and it gave me the same error. > > But although 'python ./pySim-read.py -p0' works (reads out the content of > the SIM, it gives me an error/prompt at the end: > Traceback (most recent call last): > File "./pySim-read.py", line 255, in <module> > (res, sw) = card.read_ehplmn() > AttributeError: 'OpenCellsSim' object has no attribute 'read_ehplmn' > > maybe I can just ignore this prompt as I don't need ehplmn. > > Br, > Andrew > > On Tue, Dec 1, 2020 at 12:45 AM Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> > wrote: > >> On 12/1/20 2:17 AM, Chunlin Yang wrote: >> > ModuleNotFoundError: No module named 'smartcard' >> > >> > BTW, I have manually imported smartcard in python, and it's successful. >> >> I guess you have two Python versions (2.7 and 3.x), so it could be that >> you've installed smartcard for 3.x and in works in the shell. >> Unfortunately, pySim has not been completely migrated to 3.x yet, so it >> starts under 2.7 by default. You can try to run it under 3.x: >> >> python3 ./pySim-read.py -p0 >> >> or install the 'smartcard' module for Python 2.7. >> >> Best regards, >> Vadim. >> >> -- >> - Vadim Yanitskiy <vyanitskiy at sysmocom.de> 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 >> >

3 years, 5 months

3
3
0 0

Help on using pysim to flash a SIM card

by Chunlin Yang

Hi All,I'm following this wiki http://osmocom.org/projects/pysim/wiki I cloned pysim repo, and I cloned this repo also: git clone https://github.com/LudovicRousseau/pyscard.git *although pcsc_scan works* But when I run below: cd <pysim-path> ./pySim-read.py –p 0 *it always gives me this error:* cd ~/pysim ./pySim-read.py -p0 Traceback (most recent call last): File "./pySim-read.py", line 36, in <module> from pySim.cards import card_detect, Card File "/home/support/pysim/pySim/cards.py", line 29, in <module> from smartcard.util import toBytes ModuleNotFoundError: No module named 'smartcard' BTW, I have manually imported smartcard in python, and it's successful. Br, Andrew

3 years, 5 months

2
1
0 0

Re: nano3g with genieACS

by Mykola Shchetinin

Hello Pierre, > Hi, could you share your gist that you have posted earlier in the > following url? > > https://gist.github.com/efistokl/b95538772e54e5edb7765021c2b5a745#22-config… I think the README.md of the repo https://github.com/Pentonet/pentonet-genieacs-package has the same contents as the gist you mentioned used to have. (I've just made the repo public) Also, the repository contains a package I used to set up my nano3g. I didn't document it at all though. Also, I think in the gist I didn't include these two fields: Device.Services.FAPService.1.CellConfig.UMTS.RAN.X_000295_DataOnFACHEnable = false (xsd:boolean) Device.Services.FAPService.1.CellConfig.UMTS.RAN.X_000295_FdEnabled = false (xsd:boolean) They are important for PS to work properly (as said by ip.access support). > I am trying to set up my nano3Gs once again and I remember reading this > awesome guide before, but when I visited the page today, sadly it was > not available anymore. Thanks, I am glad it was useful. Kind regards, Mykola

3 years, 5 months

1
0
0 0

Humor of people involved in GSM standardization

by Harald Welte

Dear Osmocom community, I'd like to share this with you, as I believe not many have read the book "GSM and UMTS; The Creation of Global Mobile Communications" by Friedhelm Hillebrand (who by the way just received the Order of Merit of the Federal Republic of Germany for his substantial contributions to mobile communications). The document (and some others on the included CD-ROM that comes with the book) reminds me to the much more widely known "Aprils Fool RFCs" within the IETF. It's a pity that ETSI - unlike IETF - didn't go through with it and hence those documents were never officially published, so that today only some fax scans seem to exist. Enjoy! -- - Harald Welte <hwelte(a)sysmocom.de> 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

3 years, 5 months

1
0
0 0

Understanding GSM BTS Tx power levels

by Mychaela Falconia

Hello GSM network side community, I am doing some research in preparation for possibly setting up my own GSM/2G BTS in my rural town of Middle-of-Nowhere, California to serve as a replacement for our current GSM/2G service provided by T-Mobile USA, a contingency plan to be activated if and when the evil corporate owners of T-Mobile shut down their 2G service. I haven't bought my BTS hardware yet - I am still doing research and comparing options, and I also need to do some other preparatory work without which the BTS won't be of any use. I have a question about GSM BTS Tx power levels. Some BTS vendors advertise models with up to 10 W power output, but I don't understand how such high power output from a BTS can be useful when MS power output in the other direction is limited to 1 W in high bands or to 2 W in low bands. The whole point of a BTS is to provide service to subscribers, and in order for a subscriber to be able to make a call or to engage in a text conversation, there has to be two-way communication between the BTS and the MS: the MS needs to hear the downlink signal from the BTS, and the BTS needs to hear the uplink signal sent by the MS. If you have a BTS that puts out 10 W on the downlink, wouldn't the effective range be limited at the point where the BTS can no longer receive the 1 W (high bands) or 2 W (low bands) uplink put out by the MS? And if the range limit is set by the Tx power limit of standard GSM MS units, what is the point of having the BTS put out more power on the downlink than the very same 1 W or 2 W limit that applies to uplink Tx power? I can only reason that I must be missing something big here, as those BTS manufacturers who offer models with 10 W output surely make such hardware for some very valid use cases - but I would like to understand it better. Can someone perhaps explain this mystery to me? TIA, Mychaela

3 years, 6 months

3
3
0 0

Osmocom C files syntax understanding

by Mario Lucas

Dear openBSC society, Would you be so kind to advise me on the following: I desire (dramatically want very much) to learn / understand Osmocom projects. I am a beginner in programming and i try to understand / learn C files that the project is build of. As an example i tried to learn / understand for example an Osmocom message buffer — msgb.h file. But immediately faced some syntax difficulties: This is the extract of msgb.h file: struct msgb { struct llist_head list; /*!< \brief linked list header */ /* Part of which TRX logical channel we were received / transmitted */ /* FIXME: move them into the control buffer */ union { void *dst; /*!< \brief reference of origin/destination */ struct gsm_bts_trx *trx; }; As it can be seen a structure «msgb» has as one of its components another structure — «gsm_bts_trx» But in whole Osmocom BB project files i could not find definition / description of struct «gsm_bts_trx». Would you kindly advise me please how to see which components / constituents / elements are in this gsm_bts_trx structure? From which components is struct gsm_bts_trx build of? Thank you so much for your kind advise. -- Mario Lucas

3 years, 6 months

1
0
0 0

Ericsson RBS-2206 startup with OSMO

by Ivan Babanov

Hello all! I'm still trying to bring onAir any of BTS in lab. Today we were trying with Ericsson RBS-2206. We limited hardware to the minimal possible setup containing: DXU-21 dTRU-1800 CDU-G 1800 And we created IDB with 1 cell 1TX 2RX After it we tried to use default config from master branch initially created for RBS-2308. It worked pretty fine except RF Power which was configured as 41dBm and 41 - 12 = 29 dBm. Value 29 was not acceptable for our RBS. I checked with Ericsson BSC Doc and found that our RBS2206 has max RF output 47dBm for DCS1800. (btw, RBS2308 has only 34dBm max output according to the same document, maybe config needs to be corrected) After setting 47dBm to config, TX-0 was configured correctly and Operational led was on. The main problem we are faced now is unavailability to perform "Enable"action on TX and RX objects and all next steps are not successful too. After getting logs from RBS (all files are attached) I see that TX and RX enabling fails with line: [20-11-03 11:51:27.264] 0\RC_HWU_TX hwu_tx_state.c:223 TRACED:TX Enable FAILED!, RCFW_ATC_State NOT Synchronized Looks like internal oscillator is not ready. So, the question is how to make internal oscillator synchronized? Could it be an E1 Sync stability issue caused by Digium cards? I remember we discussed it on earlier steps of bringing up OSMO-BSC. Now I have just 2 ideas what to do: 1. Set Digium card to get Sync from RBS. Now Digium is configured for Internal clocking and acts as master. Maybe in case when both sides will be configured to get sync from E1 it will decrease difference between internal clock of RBS and E1 and RBS will get Synced state. 2. Theoretically I can try to use Nokia DX200 BSC as a clock master for Digium and deliver sync to RBS from Digium. I'm not sure if timing accuracy is the same for Nokia and Ericsson HW. One more question is where can I find some info about timing accuracy for BTS and any possible way to check it on the existing E1 line? Thank you Babanov Ivan

3 years, 6 months

4
5
0 0

pySim incorrectly detecting as OpenCells-SIM?

by Albert Franklin

Hello I tried to buy a sysmoISIM-SJA2 but it was not available to my region, so I acquired a Chinese writable sim card with adm keys (https://www.aliexpress.com/item/32813645415.html). With their software I can read PIN, PUK, ADM, ISMI, PLMN, EHPLMN, etc exactly as on the image on the link mentioned. pcsc_scan detected it (even with a weird name) from a Chinese brand manufacture using https://github.com/LudovicRousseau/pcsc-tools/blob/master/smartcard_list.txt. I tried pySim-read and it failed on the end saying that OpenCellsSim' object has no attribute 'read_ehplmn'. I'm sharing the full output if anyone is interested. It's weird because it fails to read ISMI and ICCID for example and other fields. I started recently studying this area, I took a look at pySim code and looks like that it's based on size of data to detect if it's OpenCells or not (which I believe is not my case). Is there a easy way to know if my Chinese card is OpenCells or whatever they are? $ ./pySim-read.py -p 0 Using PC/SC reader interface Reading ... Autodetected card type: OpenCells-SIM ICCID: IMSI: None GID1: ffffffff GID2: ffffffff SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff SPN: CMCC Display HPLMN: False Display OPLMN: False PLMNsel: 32d00032d01034f06045f08032f32212f020ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PLMNwAcT: ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused OPLMNwAcT: 32d0004000 # MCC: 460 MNC: 000 AcT: E-UTRAN 32d0008000 # MCC: 460 MNC: 000 AcT: UTRAN 32d0000080 # MCC: 460 MNC: 000 AcT: GSM ... ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused HPLMNAcT: 32d0004000 # MCC: 460 MNC: 000 AcT: E-UTRAN 32d0008000 # MCC: 460 MNC: 000 AcT: UTRAN 32d0000080 # MCC: 460 MNC: 000 AcT: GSM ACC: ffff MSISDN: Not available Administrative data: 00000002 MS operation mode: normal operation Ciphering Indicator: disabled SIM Service Table: ff33ffff00003f033000f0c3 Service 1 - CHV1 disable function Service 2 - Abbreviated Dialling Numbers (ADN) Service 3 - Fixed Dialling Numbers (FDN) Service 4 - Short Message Storage (SMS) Service 5 - Advice of Charge (AoC) Service 6 - Capability Configuration Parameters (CCP) Service 7 - PLMN selector Service 8 - RFU Service 9 - MSISDN Service 10 - Extension1 Service 13 - Last Number Dialled (LND) Service 14 - Cell Broadcast Message Identifier Service 17 - Service Provider Name Service 18 - Service Dialling Numbers (SDN) Service 19 - Extension3 Service 20 - RFU Service 21 - VGCS Group Identifier List (EFVGCS and EFVGCSS) Service 22 - VBS Group Identifier List (EFVBS and EFVBSS) Service 23 - enhanced Multi-Level Precedence and Pre-emption Service Service 24 - Automatic Answer for eMLPP Service 25 - Data download via SMS-CB Service 26 - Data download via SMS-PP Service 27 - Menu selection Service 28 - Call control Service 29 - Proactive SIM Service 30 - Cell Broadcast Message Identifier Ranges Service 31 - Barred Dialling Numbers (BDN) Service 32 - Extension4 Service 49 - MExE Service 50 - Reserved and shall be ignored Service 51 - PLMN Network Name Service 52 - Operator PLMN List Service 53 - Mailbox Dialling Numbers Service 54 - Message Waiting Indication Status Service 57 - Multimedia Messaging Service (MMS) Service 58 - Extension 8 Traceback (most recent call last): File "./pySim-read.py", line 255, in <module> (res, sw) = card.read_ehplmn() AttributeError: 'OpenCellsSim' object has no attribute 'read_ehplmn' As I can't buy the sysmoISIM-SJA2 where I live, I searched for other sellers. I found this one (https://www.aliexpress.com/i/32272726951.html) where an user wrote "+ Devices work. + Use GRSIMWrite to program them initially. After you do this, you will know PIN-ADM so then pysim will work. - PsiWords could spend a little time pointing people at correct software to program cards. That would be, as they like to say, much more professional! (Especially if they want repeat business!) 21 Aug 2018 16:43". I'm curious if this card sold by other user just have a different encoding / format to read/write data from mine, because the PIN + ADM keys I also can obtain from their software, however, since my card is in another format I don't believe that I will have success to write it. Am I wrong? I saw the list of supported SIM cards and some of them are very limited. Someone already acquired a SIM card with great compatibility with pysim from China? I searched for supersim, fakemagicsim and some combinations and no success. fakemagicsim supersim magicsim grcardsim sysmosim-gr1 sysmoSIM-GR2 sysmoUSIM-GR1 sysmoUSIM-SJS1 Fairwaves-SIM OpenCells-SIM Wavemobile-SIM sysmoISIM-SJA2 Any help or advise is very welcome. -- Sent with https://mailfence.com Secure and private email

3 years, 6 months

1
0
0 0

osmo-st-* projects

by Mykola Shchetinin

Hello there! The question out of curiosity. Hard to not notice quite a few of projects written in Smalltalk. Why was cellular network implementation in Smalltalk abandoned? Or was everything in C initially and you just tried out Smalltalk as a possible alternative? What was your thinking back then? Interested to know some history. Thanks a lot! P.S. of course, I see some stuff in Erlang as well, but it has an awesome Diameter support which kind of answers a similar question but related to Erlang.

3 years, 6 months

2
1
0 0

Final death of the NITB, really this time.

by Keith

Hi all, I just noticed that osmo-bts commit 6d117891c93da969e0ff8b293bef97c699490f2b is the last version that can be brought up by the openBSC aka osmo-nitb. Which makes me wonder now, should the openbsc / osmocom-nitb package continue to be published to repositories?

3 years, 6 months

2
1
0 0

GGSN operation / feature

by Keith

Hi All, I have scanned 3GPP documents for info on the GGSN IP network facing side, IIUC how the GGSN responds there is "out of scope" - I'm specifically wondering about sending ICMP host unreachable messages in response to packets for IPs that are not currently active in the pool. Sometimes it would happen where I was pinging an IP assigned to an MS while looking at other things in the SGSN and PCU but in the meantime the MS would cycle the PDP context and have a new IP. For this and maybe other reasons I wrote a proof of concept, probably not great code, but working, patch to have the GGSN send ICMP host unreachable. Do you think this is a desirable feature? If so I would try to clean it up and submit to code review. Also if in agreement, would it be worth making it switchable via a vty param? I am thinking of where one might not want the IP space to be probable, although I would assume that kind of thing is best left to the local firewall implementation. Patch here: http://git.osmocom.org/osmo-ggsn/?h=keith%2Ficmp Thanks. K.

3 years, 6 months

2
1
0 0

Re: NMT-450

by Sipos Csaba

Hi Andreas, I pulled the new master, rebuilt my setup from source in a clean state and it works as it should. One more question though: is it possible to use the MNCC socket to connect the NMT-450 network to 2G (via Osmo-BSC), or to SIP via LCR? Thanks again! Regards, Csaba

3 years, 6 months

2
1
0 0

GSUP <> MAP Conversion

by a.valizadeh＠sinacomsys.com

Hi! i'm very interested about GSUP <-> GSM MAP protocol conversion to perform HLR interrogation. Do you suggest a suitable solution for this problem? is there some related activity at OSMOCOM project?

3 years, 6 months

2
1
0 0

Re: OpenBSC Digest, Vol 72, Issue 18

by Sipos Csaba

Hi Andreas, Fixed the patch. Yes there is a gap in the middle, that is why it is split to two: 1..72 and 132..239 is the correct one and it uses a reverse numbering like the Slovak or Czech networks. This is the reason the NMT phones in Hungary was not compatible with any other country, and the phones country settings were locked to Hungary only. For example in my MCR4800XL the country cannot be set, yet if you read out the EPROM, it contains the country settings for all country, but it is locked down to Hungary only. Regards, Csaba <openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2020. okt. 28., Sze, 13:00): > Send OpenBSC mailing list submissions to > openbsc(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/openbsc > or, via email, send a message with subject or body 'help' to > openbsc-request(a)lists.osmocom.org > > You can reach the person managing the list at > openbsc-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenBSC digest..." > > > Today's Topics: > > 1. [PATCH] Adds country specific settings for Hungary. (Sipos Csaba) > 2. Re: [PATCH] Adds country specific settings for Hungary. > (Andreas Eversberg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Oct 2020 19:08:46 +0100 > From: Sipos Csaba <dchardware(a)gmail.com> > To: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> > Subject: [PATCH] Adds country specific settings for Hungary. > Message-ID: > <CALQr=E9WMDr_-KBwWdQAH=UgB88nd= > ph2p1G2dOSG8F_CtY_Jg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > This is the final patch for Hungary specific settings for the > osmocom-analog project. > > Tested against a locked Motorola MCR4800XL, it works on all channels and > TAs. > > Please let me know if any more work needs to be done. > > Regards, > Csaba >

3 years, 6 months

2
1
0 0

[PATCH] Adds country specific settings for Hungary.

by Sipos Csaba

This is the final patch for Hungary specific settings for the osmocom-analog project. Tested against a locked Motorola MCR4800XL, it works on all channels and TAs. Please let me know if any more work needs to be done. Regards, Csaba

3 years, 6 months

2
1
0 0

Fwd: NMT-450 - partial success

by Sipos Csaba

Hi, I know it is a bit off topic, but as osmocom-analog has no dedicated mail list and my every attempt to contact Andreas lead to silence, I thought this is the closest one to discuss it. I try to create an NMT-450 network with Motorola MCR4800XL phones, and a LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster and a large gap in the middle, first I needed to dig out the details, find out the country code and create a patch so at least the phone is willing to lock onto the DS signal. I managed to do all that, so now the phone is actually able to decode the network and lock onto the signal. My issue is with the uplink: when the phone tries Traffic Area update (the phone's uplink transmission burts is clearly seen with a spectrum analyzer), the network side is not able to detect the uplink burst at all. Not even as bad, or incorrectly formatted frame. Andreas has a site which describes how to set up the uplink side and do some tests: http://osmocom-analog.eversberg.eu/docs/sdr.html I followed that guide and when the uplink burst from the phone arrives, the RX IQ constellation monitor indicates a correct burst with proper power (the burst is nicely round and in the green area). If I try to set up a call to the phone using the correct country code and phone number, the phone clearly responds to the paging request, as the 3 paging attempt generates 3 uplink bursts. Again, with no reception/decoding on the network side. Tried with two phones of the same type, the effect is the same. I have two questions: 1. Where to send patches for the osmocom-analog project? 2. Does anyone have an idea what can be wrong with my setup? One more thing I noticed: compared to the channel frequency used to set the NMT network up, the uplink is a couple kHz shifted: http://www.imagebam.com/image/d17e881357285965 As it can be seen, the uplink burst appears 3-4kHz left relative to the downlink signal. The network is started with the following command: nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20 Any and all help is appreciated. Regards, Csaba

3 years, 6 months

3
6
0 0

[PATCH 0/1] pysim: make random seed function python3 compatible

by Jeremy Herbert

Currently the random seed function _digits is not python3 compatible as it passes a unicode string to the sha1 function. It generates the following exception: Using PC/SC reader interface Card programming failed with an execption: ---------------------8<--------------------- Traceback (most recent call last): File "./pySim-prog.py", line 718, in <module> rc = process_card(opts, first, card_handler) File "./pySim-prog.py", line 643, in process_card cp = gen_parameters(opts) File "./pySim-prog.py", line 342, in gen_parameters iccid += _digits(opts.secret, 'ccid', ml, opts.num) File "./pySim-prog.py", line 228, in _digits s = hashlib.sha1(secret + usage + '%d' % num) TypeError: Unicode-objects must be encoded before hashing ---------------------8<--------------------- This patch fixes this problem. Jeremy Herbert (1): make random seed function python3 compatible pySim-prog.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.25.1

3 years, 6 months

2
4
0 0

libosmocore: macOS support?

by Ludovic Rousseau

Hello, I try to build utils/osmo-sim-test.c on macOS. For that I need to build the complete libosmocore project. I already patched/hacked some source code file to make them compile on macOS but now the compiler fails on src/vty/cpu_sched_vty.c because cpu_set_t is Linux-specific. The problem is that src/vty/cpu_sched_vty.c contains *a lot* of use of cpu_set_t usage. I am pretty sure utils/osmo-sim-test.c will not need the functions defined in cpu_sched_vty.c. Is it possible to build utils/osmo-sim-test.c without building the complete libosmocore project? Any interest in macOS support (even partial & unofficial support)? Yes, the easiest option is to use Linux. But my main computer uses macOS. And I like challenges :-) Regards, -- Dr. Ludovic Rousseau

3 years, 7 months

2
1
0 0

E1 line debug L1/L2

by Ivan Babanov

Hello all, Brief question. Is it possible to debug E1 line by connecting it to the 2nd port of the same NIC making a wired loop? Is it enough to open->ioctl->read from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted by BSC? A bit more details for those interested I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC. I'm using an E1 card Digium TE405P on the server side. OSMO-BSC is connected with Nokia BTS via a single E1 line. Looks like on Level1 everything is ok because BTS can detect the link and raise an alarm if the wire is getting disconnected. I can observe some data from timeslots on BTS side and if some channel is configured as D-Channel in /etc/dahdi/system I see transmission of block "01111110". But the problem is that LAPD link is not establishing. I can't find any tries on BTS side and BSC does not receive anything from BTS, just set of SABME messages in PCAP file. T200 expires and so on. I tried various T200 values. So, now it looks for me like L1 does not receive anything from L2 on BSC side and nothing is transmitted over the wire to BTS. dahdi_tool shows status "OK" So, my nearest plan to check data transmission over wired loopback. Thank you Babanov Ivan

3 years, 7 months

4
10
0 0

Osmocom Phone forcing encryption

by Radiarisainana Sitraka

Hello,i would like to ask if it's possible to forcing the encryption of osmcom phone like A5/1 or A5/2 or A5/3? How to process it? Chears,

3 years, 7 months

2
1
0 0

Application specific VTY attributes

by Vadim Yanitskiy

Hi Philipp, while reading your comments to: https://gerrit.osmocom.org/c/osmo-bsc/+/19670 https://gerrit.osmocom.org/c/osmo-mgw/+/20250 I realized that it would be better to discuss here. My initial idea was that the absence of attributes (in the command definition and thus in the VTY reference) implicitly indicates that a given VTY command in the 'config' node comes into effect immediately. This way we would only need to add attributes to commands requiring program restart or reestablishment of some link(s) / connection(s). However, in some applications *most* of the commands may require full program restart. Or the opposite: most commands may apply immediately. Adding same attributes to every command is annoying, so I came up with a concept of default 'applies when' policy: what if we add a new field to 'struct cmd_node' indicating default attributes of all commands belonging to it? struct cmd_node foo_node = { .node = FOO_NODE, .prompt = "%s(config-net)# ", .vtysh = 1, .usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!) }; This way a DEFUN() command definition would inherit foo_node.usrattr, and a DEFUN_USRATTR() command definition would override it. dexter wrote: > I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in > libosmore. Almost any of the osmo program will need it. Maybe also an > VTY_ATTR_RESTART_IMMEDIATE? ACK. I think they could be even moved to generic attributes: /*! Attributes (flags) for \ref cmd_element */ enum { CMD_ATTR_DEPRECATED = (1 << 0), CMD_ATTR_HIDDEN = (1 << 1), CMD_ATTR_APPLY_IMMEDIATE = (1 << 2), CMD_ATTR_APPLY_FULL_RESTART = (1 << 3), }; dexter wrote: > Maybe we could have some standard letters defined in libosmocore > for standard situations: > F = Full restart required > I = Applied Immediately ACK. We can also agree that generic (pre-defined) attributes use upper case letters, while the application specific ones use lower case? What do you think about these ideas? If you agree, and nobody has any objections, I can quickly implement them in libosmocore. Would be also nice to know what other developers think. Neels, Harald, Pau, Daniel? Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> 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

3 years, 7 months

4
10
0 0

gerrit upgade / new syntax for push to topics

by Harald Welte

Dear all, I did a major upgrade from the (unsupported) 2.16.x gerrit version to the latest 3.2.x series. For a detailed list of changes, please see the documentation / changelog. At least one change affects our day-to-day usage: How to push to a 'tpopic'. While in the past we would have done something like git push gerrit HEAD:refs/for/master/fr we now need to write git push gerrit HEAD:refs/for/master%topic=fr Don't ask me why that change was made... 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)

3 years, 7 months

1
0
0 0

libosmocore stderr log performance / blocking

by Harald Welte

Hi! >From time to time we've been discussing logging related stalling of osmocom programs, particularly in the context of the stderr log target. In general, when we log to stderr, we perform a blocking, buffered write. So any slow output on stderr will slow down the entire osmocom program. I've taken some time to play with this using bpftrace and usdt (static userspace probes) in order to determine the latency of log statements in osmocom programs. My test program doesn't do anything else but an endless LOGP() of verying length (from 1..512 characters). It was executed on a Lenovo Thinkpad X260 (i7-6600U, 16GB RAM, SATA SSD with btrfs on top of dm-crypt). I've compared * launching the program in uxterm * launching the program in gnome-terminal * launching the program in screen (detached) * launching the program in screen (attached; printing via uxterm) * launching the program with 2>/dev/null * launching the program with 2>/file/on/btrfs/on/ssd * launching the program from systemd (with journald) * replacing stderr logging with gsmtap log target (without wqueue) The resulting histograms of the time spent for writing the logs are below. The git repo containing the test program, the libosmocore usdt patch and the bpftrace program can be found at git://git.osmocom.org/laforge/osmo-logbench.git == launching the program in uxterm @usecs: [2, 4) 30 | | [4, 8) 199963 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 82294 |@@@@@@@@@@@@@@@@@@@@@ | [16, 32) 6897 |@ | [32, 64) 1649 | | [64, 128) 57 | | [128, 256) 221 | | [256, 512) 8588 |@@ | [512, 1K) 13062 |@@@ | [1K, 2K) 144 | | [2K, 4K) 14 | | [4K, 8K) 3 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 28 | | == launching the program in gnome-terminal @usecs: [2, 4) 32387 |@@@ | [4, 8) 457668 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 44408 |@@@@@ | [16, 32) 466 | | [32, 64) 63 | | [64, 128) 9 | | [128, 256) 3 | | [256, 512) 53 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 1 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 39 | | [64K, 128K) 125 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | So we can see that gnome-terminal tends to be faster on most stderr-writes, but at the expens of introducing a few long-delays in the 32..128ms bucket. == launching the program in screen (detached) @usecs: [2, 4) 107649 |@@@@@@@@ | [4, 8) 699672 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 15262 |@ | [16, 32) 622 | | [32, 64) 5840 | | [64, 128) 42728 |@@@ | [128, 256) 14000 |@ | [256, 512) 68 | | [512, 1K) 3 | | [1K, 2K) 0 | | [2K, 4K) 1 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 50 | | * launching the program in screen (attached; printing via uxterm) @usecs: [2, 4) 2 | | [4, 8) 67887 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 30378 |@@@@@@@@@@@@@@@@@@@@@@@ | [16, 32) 58881 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [32, 64) 5188 |@@@ | [64, 128) 301 | | [128, 256) 61 | | [256, 512) 3963 |@@@ | [512, 1K) 7603 |@@@@@ | [1K, 2K) 407 | | [2K, 4K) 42 | | [4K, 8K) 20 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | so intrestingly, attaching the screen will significantly slow down stderr. It seems screen doesn't do sufficient buffering internally, or it blocks the osmocom program until not only it has updated its internal buffer, but also written to the output of the attached uxterm? == launching the program with 2>/dev/null @usecs: [1] 2202080 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [2, 4) 26966 | | [4, 8) 1107 | | [8, 16) 305 | | [16, 32) 10 | | [32, 64) 6 | | [64, 128) 0 | | [128, 256) 0 | | [256, 512) 1 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 153 | | unsurprisingly, this turns out to be rather fast == launching the program with 2>/file/on/btrfs/on/ssd @usecs: [2, 4) 2275464 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4, 8) 265612 |@@@@@@ | [8, 16) 9384 | | [16, 32) 368 | | [32, 64) 4 | | [64, 128) 24 | | [128, 256) 3 | | [256, 512) 1 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 95 | | I've tried creating some load using a cocnrrent dd of the underlying block device, but couldn't make out any difference. I guess this shows how good the I/O subsystem is. Yes, some writes are slower than writing to /dev/null, but == launching the program from systemd (with journald) [2, 4) 1060607 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4, 8) 75133 |@@@ | [8, 16) 724 | | [16, 32) 107 | | [32, 64) 8 | | [64, 128) 8 | | [128, 256) 0 | | [256, 512) 0 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 38 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | This is also pretty fast. There are some writes in the 64..128ms range, though. Those are likely going to cause problems in timing critical programs like osmo-bts, osmo-trx or osmo-mgw. * replacing stderr logging with gsmtap log target (without wqueue) @usecs: [4, 8) 776978 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 1771 | | [16, 32) 60 | | [32, 64) 0 | | [64, 128) 1 | | [128, 256) 0 | | [256, 512) 0 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 0 | | [2G, 4G) 82 | | Ignoring the strange (and certainly bogus) artefacts in the 2..4s bin at the bottom, writes to the GSMTAP UDP socket tend to be quite fast, much faster than anything via stderr. Even faster than stderr-to-dev-null. == conclusion all-in-all, it looks not too bad at least on a relatively unloaded couple-of-years-old laptop. I would have expected worse. We can definitely see that there are non-neglectable delays created by both systemd/journald as well as gnome-terminal. One idea would be to play with setvbuf(3) to increase stderr buffering inside libc. The other idea would be to do our own buffering using osmo_wqueue() on the raw, unbuffered stderr-fd, which would then be in non-blocking mode and handled vis osmocom select. We'd have to add some kind of limit for that buffer in order to avoid OOM situations. -- - 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)

3 years, 7 months

4
10
0 0

Fwd: OpenAirInterface releases 5G core network code

by Neels Hofmeyr

Possibly interesting to note this OAI announcement. Unfortunately none of the links are direct, but all of them are ugly tracking links. Also ads for facetwoogle. So I had to blank out a lot. Also interesting to note how they don't self-host, but rather spread their code across *both* hosted-gitlab and github. Also interesting how the From: address is a gmail one vs. the contact(a)openairinterface.org further below. In a massive herd effort, folks are fudging up the internet, no news there at least. ~N ----- Forwarded message from OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> ----- Date: Fri, 25 Sep 2020 05:40:17 +0000 From: OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> To: nhofmeyr(a)sysmocom.de Subject: OpenAirInterface releases 5G core network code X-Mailer: MailChimp Mailer - **CIDbb030ed5232925faf6b6** ** OpenAirInterface releases 5G core network code ------------------------------------------------------------ Dear Community, The OpenAirInterface Software Alliance is pleased to announce the release of the OAI 5G Core Network code. An initial set of features is already available and developments with a solid team are underway to build the rest of the 3GPP 5G SBA core. The project home page is here (<blanked-tracking-link>) and gives a good overview of the development phases and the roadmap. The AMF (<blanked-tracking-link>) and the SMF (<blanked-tracking-link>) code is available on GITLAB. While working to release the UPF code, we are working with the SPGW-U (<blanked-tracking-link>) on the GITHUB. A CI bench is already operational and in place. Any new features or developments introduced by community developers will automatically launch the CI pipeline and changes will only merge after having thoroughly been tested against third party testers and the OAI 5G RAN test benches. We cordially invite the community to contribute to the developments of the OAI 5G core network and reach out to contact(a)openairinterface.org for any questions and contribution proposals. The OpenAirInterface Software Alliance Team* [removing a ton of tracking links] ----- End forwarded message -----

3 years, 7 months

2
1
0 0

Structure alignment problems in PCUIFv9 and PCUIFv10

by Vadim Yanitskiy

Hi all, we seem to have problems with structure alignment in the new version of the PCUIF protocol: PCUIFv9: sizeof(struct gsm_pcu_if) -> 212; 212 % 4 == 0 PCUIFv10: sizeof(struct gsm_pcu_if) -> 1006; 1006 % 4 != 0 I think we would need to add/remove some padding. The question is whether we should make sure that all structures are aligned, or having the top level struct gsm_pcu_if aligned would be enough? Even in PCUIFv9 not all structures are properly aligned: sizeof(struct gsm_pcu_if_data_cnf_dt) -> 21; 21 % 4 -> 1, sizeof(struct gsm_pcu_if_rts_req) -> 13; 13 % 4 -> 1, sizeof(struct gsm_pcu_if_rach_ind) -> 15; 15 % 4 -> 3, sizeof(struct gsm_pcu_if_pag_req) -> 11; 11 % 4 -> 3, sizeof(struct gsm_pcu_if_susp_req) -> 11; 11 % 4 -> 3. I devise by 4 because the widest member is uint32_t in all cases. Kind regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> 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

3 years, 7 months

2
2
0 0

working dahdi config for Ericsson RBS 2000

by Ivan Babanov

Hello! Can anybody share a working /etc/dahdi/system.conf file? I'm trying to bring up RBS 2000 with osmo-bsc and I'm not sure that I have correct configuration. 1. Which signaling should be used? CAS? CCS? RBS? 2. There is the same thing with framing. hdb3? 3. parameter "dslot=1,4" pointed in RBS2000 wiki looks wrong. dahdi_cnf does not work with it at least now. Thank you Ivan

3 years, 8 months

2
1
0 0

Re: Support for new SDR devices

by Harald Welte

Hi Xaver, [posting this on the mailing list, as it may be of interest to others] On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote: > This is a dynamic linking. this is true, but the nature of the linking does not matter in terms of what creates the derivative work. > Is this a problem even if I do not distribute the resulting binary? The AGPL (contrary to the GPL) conditions start when users remotely interact with your software (See Section 13 of AGPLv3). This means even operating a network with remote users already means you need to provide the complete and corresponding source code to the entire work under AGPLv3, which is impossible if you have a proprietary dependency. So if you build the software, and you make sure that nobody but yourself every uses the resulting GSM network, you are fine. But as soon as any third party uses it, you would be putting yourself in the impossible position to providing the source code to a proprietary library. > I can simply add a warning to the file that the compiled program cannot be distributed. One might consider this a "further restriction" which by itself is a violation of AGPLv3: All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. [...] You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. But even beyond that: How many users do you think willread that warning in the source code vs. how many will simply run it (and possibly allow others to register). Even if you added a message to start-up, and to the user manual, I still would think many people don't look at that. I don't think we should distribute something that "tricks" people into committing license violations or putting them in an impossible position, legally speaking. > Is it a violation that someone assembles and uses it on their own machine? It is not a violation as long as they are they only person using the resulting GSM network (or using its VTY or its TRXC/TRXD interface). I would compare distributing source code like that to shipping a product that is almost impossible to use safely, but very easy to use in a [legally] unsafe way. > Is it a violation to even have sources and build instructions for it? Maybe not, but see above, I don't want to make it too easy for people to shoot themselves into their foot. > Can we agree to leave it as a starting point until someone will have the > time to do it using IPC? I'm very sorry (really), but we will not merge this code to the mainline osmo-trx code base on osmocom.org. Kind 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)

3 years, 8 months

4
13
0 0

Alternatives to CalypsoBTS?

by Mychaela Falconia

Hello GSM network side folks, I assume that most of you are probably aware of the existence of a certain hack called CalypsoBTS: it's a rather unbelievable hack that takes a piece of hw meant to be a GSM MS and turns it into a poor man's GSM BTS, all inherent asymmetry in the GSM air interface be damned. As a manufacturer of Calypso-based GSM MS devices I occasionally get approached by people who seek to acquire a Calypso device seemingly for the sole purpose of running that CalypsoBTS hack, and every time I get approached by someone of that sort, I always shake my head in bewilderment - isn't there a better way to get your own little toy BTS running than to misuse GSM MS hardware? The purpose of the present post is to solicit advice from the community as to what I should tell those poor souls who are seeking to set up their own toy BTS and are looking to do it via the CalypsoBTS route - is there some better way that we as a community can steer them toward instead? It is my understanding - please correct me if I'm wrong - that the least expensive way to set up your own GSM BTS for toy purposes (as opposed to running a real operational GSM network which people will depend on for real communication) is to use a generic SDR device of one of several types that are supported by osmo-bts-trx/osmo-trx - but this is where my knowledge in this area ends, as this particular mode of GSM toying has never been an area of interest for me. But for those people who (unlike me) *are* interested in setting up their own toy BTS in the least expensive way, what SDR hardware should we as the community recommend for them? What is the cheapest option that will be good enough - especially if the criteria for "good enough" are compared to CalypsoBTS? What would be the least expensive option that is just good enough to be advocated as a better alternative to the CalypsoBTS hack? In the case of my current FCDEV3B hardware the price tag seems to be an effective deterrent against people misusing it as CalypsoBTS: FCDEV3B is expensive, and someone whose actual need is to run their own BTS rather than MS can easily buy a suitable SDR device for the same price or less, it seems. But the issue is beginning to rear its ugly head again because I have another development board in the works (not here yet, probably won't have the hw until December), and there is a possibility (nothing is certain yet) that it might be a bit less expensive than FCDEV3B. Is there an SDR-based option (or any other non-CalypsoBTS option) for running a toy BTS with osmo-bts-trx and the Osmocom CNI stack behind it that would cost $250 or less in hardware? The $250 number comes from my anticipated-around-December new FreeCalypso development board - there is a chance that it might be that cheap (but again, absolutely nothing is certain at the present moment) - and if there is no SDR or other option for running your own toy BTS for the same or lower hw price, then I fear that I am going to be flooded with support requests from people asking for help with using my new board as CalypsoBTS, which I absolutely dread. Hence my present attempt to pre-emptively seek some better solution for those people. (It would be nice if that stream of support requests from people seeking to run the CalypsoBTS hack could be redirected to Sysmocom or some other commercial entity who could make some money helping those people, but my experience is that these people are not the kind who would ever pay for commercial support, so no hope there...) It may also be worth mentioning that the filter replacement hack (removing or replacing Rx SAW filters that are meant to limit the GSM MS device's Rx capability to only specific GSM downlink bands) will not be possible on the new FreeCalypso GSM MS board that will be coming around December - that design uses an integrated RF FEM (front end module) instead of discrete antenna switch and SAW filter components. But I've also heard that plenty of people run the CalypsoBTS hack without doing any filter rework, just letting the strong signal from a nearby GSM MS force its way through wrong SAW filters and not caring about the 40 dB or so of attenuation being incurred - I cringe at the thought, but that's what people do... M~

3 years, 8 months

3
4
0 0

Question on osmo-trx mcbts

by Harald Welte

Hi Thomas, it's been some time, hope you're doing fine! Today on IRC we were collectively wondering about one detail in the osmo-trx mcbts implementation that has been there from day one: Your're creating the Channelizer and Synthesis class for four channels of 800kHz within the 3.2Mbps wideband-channel. So far so good. But why does the code ever only use up to three of them? And why is there a specific re-ordering, see radioInterfaceMulti.cpp in getLogicalChan() ? It would be great if you could share your thoughts on that. To me, it looks like the constraint to 3 channels is arbitrary and we should just as well be able to use all four? Thanks, Harald -- - 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)

3 years, 8 months

2
2
0 0

Fwd: Support for new SDR devices

by Xaver Zu

That library does a lot of work. Configures HW, sends samples to FPGA via DMA, does calibration, normalization, format conversions ... Highly optimized for Intel CPU. If everything were to be done in an equivalently closed version, it would take several years of work for me. I would like to start with a simple proof-of concept. Implementing only the functions used in osmo-trx-pciesdr. In the first phase, these can be only dummy functions writing or reading zeros. I assume that the GPL violation problem will be solved from the moment I will be able to build the library and link it with osmo-trx and run it. The next step is just a matter of effort from anyone in the community. Xaver

3 years, 8 months

1
0
0 0

Re: Support for new SDR devices

by Harald Welte

Hi Xaver, On Fri, Sep 11, 2020 at 07:51:50AM +0200, Xaver Zu wrote: > I created a short Wiki page. Please see if it's enough as a link to a > commit message. > https://osmocom.org/projects/sdr/wiki/PCIeSDR Thanks. For sure it is sufficient in terms of content. I did some minor reformatting while reading. However, I found a major problem. You state: > The higher-level driver (in userspace) includes a DSP, a calibration stage, and the gateware update. It is in the form of a closed source dynamic library named libsdr.so. The C API for Linux / x86 is in the form of a header file libsdr.h which also serves as brief documentation. This is incompatible with the strong copyleft licensing (AGPLv3) of osmo-trx! You cannot directly link with a proprietary library. The only way I can see a PCIeSDR backend for osmo-trx would be via osmo-trx-ipc, which provides a general-purpose sharde memory interface to another process. The other process can then use the non-free library, if you want that. -- - 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)

3 years, 8 months

1
0
0 0

OsmoDevCon / COVID-19

by Harald Welte

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - 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)

3 years, 8 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC