10 May
2016
10 May
'16
4:01 a.m.
Hi Keith,
On May 5, 2016 6:02 PM, "Keith" <keith(a)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
10 May
10 May
7:32 a.m.
New subject: strange file names in log (was Re: Persistent Uplink activity from Moto KRZR K3)
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?
--
- 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)
8:52 a.m.
New subject: strange file names in log (was Re: Persistent Uplink activity from Moto KRZR K3)
On 10 May 2016, at 13:32, Harald Welte
<laforge(a)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
9:53 a.m.
New subject: strange file names in log (was Re: Persistent Uplink activity from Moto KRZR K3)
On Tue, May 10, 2016 at 2:32 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Tue, May 10, 2016 at 11:01:26AM +0300, Alexander
Chemeris wrote:
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.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
> <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? 
10:45 a.m.
New subject: strange file names in log (was Re: Persistent Uplink activity from Moto KRZR K3)
On 10 May 2016 12:32:17 GMT+01:00, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Keith,
Hi!
On Tue, May 10, 2016 at 11:01:26AM +0300, Alexander Chemeris wrote:
I agree!
I was going to remove the ../../ from the post, but i'm glad i didn't now.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
> <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. 
10:51 a.m.
New subject: Persistent Uplink activity from Moto KRZR K3
On 10 May 2016 09:01:26 GMT+01:00, Alexander Chemeris <alexander.chemeris(a)gmail.com>
wrote:
Hi Keith,
Hi!
On May 5, 2016 6:02 PM, "Keith"
<keith(a)rhizomatica.org> wrote:
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.
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.
26 May
26 May
8:29 a.m.
New subject: GSM MAP invoke? (was Re: Persistent Uplink activity from Moto KRZR K3)
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.
3338
days inactive
3354
days old
6 comments
5 participants
participants (5)
-
Alexander Chemeris -
Harald Welte -
Holger Freyther -
Keith -
Kino＠Rhizo