Hi Lorenzo, On Thu, Sep 06, 2018 at 10:43:56AM +0200, Lorenzo Cavallini wrote:

I think the branch is not upstream yet, on osmo-bts.git I can see only these ones:

this is very odd. the branch had been pushed to gerrit, and I can verify exists on gerrit when cloning using git clone https://gerrit.osmocom.org/osmo-bts Still, gerrit doesn't seem to be replicating this to git.osmocom.org. Odd. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

On Thu, Sep 06, 2018 at 11:12:29AM +0200, Lorenzo Cavallini wrote:

yes I cloned it now from gerrit and the branch is definitely there.. that's fine for me anyway, thanks!

After restarting gerrit, it appears to have replicated to git.osmocom.org now, too: http://git.osmocom.org/osmo-bts/log/?h=laforge/cbch-trx -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Lorenzo, On Mon, Sep 10, 2018 at 08:14:49AM +0200, Lorenzo Cavallini wrote:

thanks for the update! I'll check as soon as I can and I'll let you know.

Any news yet? I've meanwhile developed a related test suite for osmo-bts (see http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/cbch&id=7048dc207a...) as well as discovered + fixed a wireshark RSL dissector bug related to RSL CBCH (https://code.wireshark.org/review/29683). -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Lorenzo, On Mon, Sep 17, 2018 at 10:41:16AM +0200, Lorenzo Cavallini wrote:

yes I have some updates. I tested with two different timeslot configurations: CCCH+SDCCH4+CBCH on ts0 and SDCCH8+CBCH on ts1.

In both cases I'm using an iPhone8 to test.

iPhones are generally known to have (together with at leats older Blackberries) the most "critical" protocol stacks out there, i.e. they will bail out the first time they see any single bit that is not like they expect it. So in general, it might be worth to also test with other phones and compare.

With the first ts configuration, the iphone could not perform the location update procedure, so basically I had no connectivity to the basestation.

the qeustion is which particular commit you were using at the time. There is one fix that might be related to this: commit 526b4a5f350725d312c6739cf6abdcef040b698c Author: Neels Hofmeyr <neels@hofmeyr.de> Date: Tue Sep 11 00:47:29 2018 +0200 ts,lchan_fsm: do not attempt to allocate CBCH subslots Also, please noe that as per GSM spec, if you use the CBCH on SDCCH/4, you *must* advertise BS_AG_BLKS_RES >= 1 to achieve a valid configuration.

Let me know if this helps and what kind of debug I can provide you, as you may guess getting debug out of mainstream smartphones is not really easy, so what I can do is limited on that side.

I think particularly the big trouble in the SDCCH/4 case should be possible to debug with traces only from the network side. If you can provide pcap files with * GSMTAP (containing at least BCCH,CCCH,SDCCH,CBCH SAPI) * Abis OML and RSL (tcp port 3003 + 3002) during the time where you tried to register the phone unsuccessfully, it would help. Also, please double-check if the commit above by Neels makes a difference. I'll also try to reproduce this here today using a LimeSDR-USB and current osmo-bts / osmo-bsc master and a couple of phones. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Lorenzo, On Tue, Sep 18, 2018 at 11:30:58AM +0200, Lorenzo Cavallini wrote:

I've seen the latest commits and tested them. I can confirm that now SMSCBs are working in the CCCH+SDCCH4+CBCH configuration,

great!

however the funny part is they're working on my extremely old, pre-iPhone era Samsung mobile phone, where I can receive the smscb message.

FYI, even the (to me hyper-modern) Samsung Galaxy S5 decodes the messages here. I mostly work with >= 10 year old feature phones during development, as their UI is inside the baseband processor and closer to what happens on the GSM protocol side than all the smartphones that go via AT-commands or QMI.

Anyway, the location update procedure is successfully completed in all three phones I've tested.

that's great and confirms the related bug is fixed.

I'll do other tests meanwhile and try to understand why they're not being displayed by "modern" phones, most likely they're being blocked in the baseband before reaching Android/iOS.

I'm not sure why that is. One thing to try is to use CBCH on SDCCH/8, and also to ensure that those very same phones with their firmware/software and configuration will show SMSCB on other/production GSM networks (in 2G-only mode!!). The OsmoBTS implementation of CBCH is very conservative. * it doesn't use the optional DRX cycle * it doesn't use the optional extended CBCH * it definitely sends the blocks at the right time in the multiplex as per TS 05.02, I verified this several times The only things that I can imagine to still go wrong is message encoding, including padding (see below)

I can see some garbage text on my old Samsung, so it might be some issues with encoding.

The padding is IMHO not really fully specified. I read all relevant specs several times, and I understand there is some 7-bit-GSM-alphabet-CR used. However, the padding is specified primarily for SMS (point-to-point), and then slightly adjusted for USSD, only to then be referred that SMSCB/CBCH should also use that padding. The difference is that SMS-PP and USSD work inside LAPDm, so you do have a "length" field in a L2 header which tells you how many bytes L3 payload there are. Inside that L3 payload you need to pad using the "CR" rules, but outside the L2/LAPDm will pad with the usua 0x2B pattern. In CBCH however, you have no L2/LAPDm, but always a fixed-length frame of 88 bytes, split into four chunks of 22 bytes (each with a one-byte header as per TS 04.12). If somebody has references or sample traces that show how SMSCB is padded in the real world out there, we can try to mimic that. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Lorenzo, Try, if possible, to put a Qualcomm chipset based phone with some kind of tracing (e.g. Snoopsnitch) under testing. It might yield some results looking into the PCAP file. Wireshark dissectors can help sometimes catching wrongly coded messages - at least they helped me in the past. Good luck! Cheers, Domi 2018. szept. 19. dátummal, 13:40 időpontban Lorenzo Cavallini <lorenzo.cavallini@gmail.com> írta:

Hi,

...

On Tue, Sep 18, 2018 at 10:10 PM Harald Welte <laforge@gnumonks.org> wrote: Hi Lorenzo,

FYI, even the (to me hyper-modern) Samsung Galaxy S5 decodes the messages here. I mostly work with >= 10 year old feature phones during development, as their UI is inside the baseband processor and closer to what happens on the GSM protocol side than all the smartphones that go via AT-commands or QMI. I think the main issue is that Samsung switched baseband after the S5. I tested just now on the S7 and it's not working.

...

...

Anyway, the location update procedure is successfully completed in all three phones I've tested.

that's great and confirms the related bug is fixed. You can add iPhone7 and Galaxy S7 to the list of phones that can successfully complete the location update procedure, with the SDCCH4+CBCH configuration. On the other hand, on a very old Huawei LUA-L21 I'm not even able to receive the BCCH, my cell is not present in the list. I'm not 100% sure that's related to osmocom stack here, this phone is in a really bad shape overall, but it works without CBCH.

...

I'm not sure why that is. One thing to try is to use CBCH on SDCCH/8, and also to ensure that those very same phones with their firmware/software and configuration will show SMSCB on other/production GSM networks (in 2G-only mode!!). I'm pretty much sure that my iPhone8, Honor 9 and Galaxy S7 can receive broadcast notifications, because I get them during network tests for floods and other calamities in my country. However, I never checked if they're delivered through Paging Type 1 rest octets or through SMSCB, so this might make a difference. And to be honest I don't remember if I was in 2G only mode or not, but they test them once per month, so in about 2 weeks I can check this :)

...

The OsmoBTS implementation of CBCH is very conservative. * it doesn't use the optional DRX cycle * it doesn't use the optional extended CBCH * it definitely sends the blocks at the right time in the multiplex as per TS 05.02, I verified this several times I'm going to retest all my mobile phones with the SDCCH8+CBCH configuration and see if this makes a difference. I will let you know. Unfortunately I don't have any pre-iPhone era phones that still work beside my Samsung, so I cannot test anything else for a "positive" result. Thanks!

Regards,

Lorenzo