Hello again everyone, I have done a little more investigation into the problem of why voice calls aren't working in my OsmoCNI+nanoBTS setup. Here are my configs and a syslog excerpt showing the problem: https://www.freecalypso.org/members/falcon/osmo-cni/t200-fail-config+log.ta… The behaviour I'm seeing seems to point toward a bug in nanoBTS fw, probably tickled by the officially-unsupported combo of running it with OsmoCNI instead of whatever proprietary sw ip.access requires officially. Looking at the OsmoBSC log (captured with maximum verbosity in the posted syslog excerpt), the behaviour I'm seeing is that the BTS appears to stop successfully receiving transmissions from the MS when the lchan moves from SDCCH to TCH. For as long as the conversation with the MS stays on SDCCH, everything is happy: measurement reports from the BTS in the OsmoBSC log look good (including DL measurements received from the MS), and successful LU/SMS/USSD prove that all LAPDm control traffic passes as it should. But the moment the lchan moves from SDCCH to TCH, all subsequent measurement reports in the OsmoBSC log show "NOT VALID" for the part that comes from MS, and the UL RXQ numbers reported by the BTS are also highly suspect - usually 7. And then the BTS signals an error to the BSC, saying that T200 expired N200+1 times - whatever LAPDm exchange it is trying to do with the MS times out when the BTS is failing to receive anything sent by the MS. And then a little further down the road, the BTS declares Radio Link Failure, probably on the basis of not receiving any SACCH from the MS. All of this misbehaviour is visible in the syslog excerpt contained in the tarball linked above. If the problem is indeed a bug in nanoBTS fw that can't be troubleshot because it's a black box, then I may be SOL until I can shell out big bucks for a sysmoBTS unit to replace this nanoBTS. However, I am doing my due diligence first by demonstrating to the community the nanoBTS misbehaviour I'm seeing, and asking in the hope that someone might know of a solution. These nanoBTS units are extremely attractive for economic reasons: it's a box that is purpose-made to be a GSM BTS, rather than just an SDR from which you have to build a BTS yourself with major extra effort, yet they are often available for dirt-cheap prices - hence it would be really awesome to have these units actually work with OsmoCNI, including voice calls. The part that I find difficult to reconcile is that these nanoBTS units did once work with OpenBSC/OsmoNITB/OsmoCNI, and presumably voice calls worked too, otherwise there would have been warnings all over the docs that only SDCCH-based services work. So what has changed between the setups of other people in the past who had working Osmocom+nanoBTS combos and my present setup in which the BTS goes bonkers when the lchan moves from SDCCH to TCH? Could it be that my nanoBTS fw version is newer or older or otherwise different from what Osmocom people got to work in the past through reverse eng? Or is it perhaps the case that today's OsmoCNI sw is not tested as much with nanoBTS any more because the community moved on to OsmoBTS-based solutions, meaning either sysmoBTS or SDR platforms? Here are the versions of all Osmocom CNI components and supporting libraries I am currently running: libasn1c-0.9.33 libdbi-0.9.0 libdbi-drivers-0.9.0 libosmo-abis-1.2.0 libosmo-netif-1.1.0 libosmo-sccp-1.5.0 libosmocore-1.6.0 libsmpp34-1.14.1 lksctp-tools-1.0.17 osmo-bsc-1.8.1 osmo-hlr-1.4.0 osmo-mgw-1.9.0 osmo-msc-1.8.0 (Any non-Osmocom components in the list above are external libraries which were required for getting OsmoCNI to compile and run, but which were not already present in Slackware 14.2 and which I thus count as being strictly OsmoCNI dependencies.) My nanoBTS (PCS1900) hw and fw versions are: Equipment_Version='165b029_49' Software_Version='168d462_v200b207d0' Is there anyone in this community who still runs with nanoBTS hw (hasn't moved on to OsmoBTS-based sysmoBTS or SDR) and who has working voice calls? If any such successful Osmocom+nanoBTS users exist, may you perhaps be able and willing to share the following: * Your Osmocom sw version - the closer it is to latest OsmoCNI releases, the better; * Your nanoBTS hw and fw versions; * Your working configs for OsmoBSC and other Osmocom sw components, with any private stuff redacted out, obviously. TIA, Mychaela

Hi Harald, I just made another run and got the pcap: https://www.freecalypso.org/members/falcon/osmo-cni/session2.pcap I ran tcpdump with the following filter script: tcp port 3002 or tcp port 3003 or udp port 2427 or udp port 4729 or proto 132 which should have captured Abis between OsmoBSC and nanoBTS, SCTP carrying A, MGCP and GSMTAP. I also configured gsmtap logging in OsmoMSC and OsmoBSC for this run - are there any more components that need to have gsmtap logging enabled? I started logging after all of OsmoCNI processes were up and running (I used vty to enable gsmtap logging without saving it), but before I connected the PoE cable to the nanoBTS - thus everything from nanoBTS power-up onward should be in the log. Once nanoBTS booted up and started transmitting, I registered two phones and dialed a call from 3302 to 3301. The call failed exactly like before. M~

Hi Harald, Thanks for looking at my log! In actuality the MS was stationary during the entire test, and the fixed distance between the BTS and the MS was the distance between two rooms in one apartment turned lab - a few meters. The two MS in this test were Motorola C139 for the origin leg of the call and Pirelli DP-L10 for the destination leg. Both phones were running their respective manufacturers' original fw, i.e., no FreeCalypso fw in this test - hence FC is not to blame here. With both MS being of the standard historical type-approved variety, incorrect logic in the MS can probably be ruled out - so the finger of suspicion points at nanoBTS then? Aside from the generally unfortunate situation that the combo of OsmoCNI+nanoBTS is not officially supported by anyone, there is also the fact that this particular nanoBTS unit came from ebay in completely unknown condition - a defect can't be ruled out... I have another nanoBTS unit that is also from ebay but from a much more reputable seller, and that one is probably defect-free - but that nanoBTS is for GSM850 band, and I don't feel safe transmitting in that band without a license - looking at my SA, that GSM850 band is much more crowded than PCS1900 around here. M~