Hi Lorenzo, On Thu, Sep 06, 2018 at 10:43:56AM +0200, Lorenzo Cavallini wrote: 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(a)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: 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(a)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: 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=7048d…) as well as discovered + fixed a wireshark RSL dissector bug related to RSL CBCH (https://code.wireshark.org/review/29683). -- - 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)

Hi Lorenzo, On Mon, Sep 17, 2018 at 10:41:16AM +0200, Lorenzo Cavallini wrote: 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. 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(a)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. 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(a)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: great! 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. that's great and confirms the related bug is fixed. 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) 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(a)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(a)gmail.com> írta: