Hi Keith,
On May 5, 2016 6:02 PM, "Keith" keith@rhizomatica.org wrote:
They generate constant bursts on the uplink, and this is what I can see that corresponds from osmo-bts log output:
<0000> ../../../../osmo-bts/src/common/rsl.c:1642 (bts=0,trx=0,ts=0,ss=0) Handing RLL msg UNIT_DATA_IND from LAPDm to MEAS
REP
<0000> ../../../../osmo-bts/src/common/rsl.c:1592 (bts=0,trx=0,ts=0,ss=0) Tx MEAS RES
MEAS RES means that there is an open logical channel between the phone and the BTS. Have you looked at the list of open channels at the NITB VTY?
I might also mention that this phone fails the USSD *#100# own number request - The message "Not Successful" appears on the screen very quickly if not immediately after pressing send. There is no network communication that I can detect.
Just a suggestion - is the phone network or SIM locked?
If it's locked, it may try to send some message to the network to verify that it's connected to an allowed operator.
A useful log would be a pcap trace of communication between OpenBSC and OsmoBTS (make sure osmo-trx communication is filtered out).
-- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co
Hi Keith,
On Tue, May 10, 2016 at 11:01:26AM +0300, Alexander Chemeris wrote:
<0000> ../../../../osmo-bts/src/common/rsl.c:1642 (bts=0,trx=0,ts=0,ss=0) Handing RLL msg UNIT_DATA_IND from LAPDm to MEAS REP
How did you manage to get the "../../../../" into the filename path? I've not seen this before, normally this just states "rsl.c" or maybe common/rsl.c but not the complete path?
What are you doing to build the software this way? I think it is a complete waste of screen real-estate and I would like to do somethign about it.
Does anyone have an explanation for this?
On 10 May 2016, at 13:32, Harald Welte laforge@gnumonks.org wrote:
Hi Keith,
Does anyone have an explanation for this?
SRC != builddir. I have had something similar with newer versions of Yocto and we should replace __FILE__ with __BASE_FILE__ in the log code.
https://lists.yoctoproject.org/pipermail/poky/2015-August/010197.html
On Tue, May 10, 2016 at 2:32 PM, Harald Welte laforge@gnumonks.org wrote:
On Tue, May 10, 2016 at 11:01:26AM +0300, Alexander Chemeris wrote:
<0000> ../../../../osmo-bts/src/common/rsl.c:1642 (bts=0,trx=0,ts=0,ss=0) Handing RLL msg UNIT_DATA_IND from LAPDm to MEAS REP
How did you manage to get the "../../../../" into the filename path? I've not seen this before, normally this just states "rsl.c" or maybe common/rsl.c but not the complete path?
This happens when you build in a directory outside of the source path - e.g. we're doing this with the osmo-combo script which I think Keith is using.
So yes, Holger is right.
On 10 May 2016 12:32:17 GMT+01:00, Harald Welte laforge@gnumonks.org wrote:
Hi Keith,
Hi!
On Tue, May 10, 2016 at 11:01:26AM +0300, Alexander Chemeris wrote:
<0000> ../../../../osmo-bts/src/common/rsl.c:1642 (bts=0,trx=0,ts=0,ss=0) Handing RLL msg UNIT_DATA_IND from LAPDm to
MEAS REP
How did you manage to get the "../../../../" into the filename path? I think it is a complete waste of screen real-estate and I would like to do somethign about it.
I agree! I was going to remove the ../../ from the post, but i'm glad i didn't now.
On 10 May 2016 09:01:26 GMT+01:00, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Hi Keith,
Hi!
On May 5, 2016 6:02 PM, "Keith" keith@rhizomatica.org wrote:
They generate constant bursts on the uplink, and this is what I can
see
that corresponds from osmo-bts log output:
Just a suggestion - is the phone network or SIM locked?
If it's locked, it may try to send some message to the network to verify that it's connected to an allowed operator.
Nope, it's a factory unlocked phone, with a sysmocom SIM. I shall collect some more log and captures and try a few build combinations.
Keith.
On 10/05/2016 09:01, Alexander Chemeris wrote:
MEAS RES means that there is an open logical channel between the phone and the BTS. Have you looked at the list of open channels at the NITB VTY?
That's right, of course! Yes, there's an open channel.
A useful log would be a pcap trace of communication between OpenBSC and OsmoBTS (make sure osmo-trx communication is filtered out).
Ok, I took a look at that and compared to it other MS. - This phone sends a GSM MAP invoke Service Request right after the Location Update.
I don't know if it's more helpful for me to describe it or just send the dump, but I'm also not sure about sending the capture to the list. So.. let me go for the description route initially:
At least according to Wireshark, the MS is sending a DTAP Register, "Non Call related SS message" GSM MAP invoke interrogateSS - invoke: cfu - call forwarding unconditional, basicService: teleservice, teleservice: allSpeechTransmissionServices.
(Is that something to do with call diverts setup?) I have two of these phones, one does this, the other does not. - regardless of the inserted SIM)
The SS Version Indicator at the end of the message is 7f 01 00
This is happening as the NITB log gives: ./openbsc/openbsc/src/libmsc/gsm_04_08.c:958 <- CM SERVICE REQUEST serv_type=0x08 MI(TMSI)=1448232929 ./openbsc/openbsc/src/libbsc/gsm_04_08_utils.c:692 -> CM SERVICE ACK
And from there that channel stays open until I power off the phone.
I had a look there to see if I could trace from what happens in gsm48_rx_mm_serv_req() up to the ACK being sent, but I'm afraid I get a little bit lost in the code flow as my c skills are not really up to the task, thinking I might intervene and identify some part of this "invoke" and reject it, but there I'm really not sure how to go about it at all.
Now, I see the ack being sent from _gsm48_rx_mm_serv_req_sec_cb() but I don't really understand how this is called. I see that function name as a parameter to gsm48_secure_channel() but there I'm lost.
Any clues are most welcome!
Many thanks,
Keith.
-
Alexander Chemeris -
Harald Welte -
Holger Freyther -
Keith -
Kino＠Rhizo