Hi All,
A few weeks ago, I wrote to the list about a handset that was opening and holding an lchan after doing IMSI attach. After some investigation I see this phone is querying the network for call forwarding status. This phone then cannot send any more USSD codes, or make calls, although it can receive, but for some reason insists on doing the query again after call termination.
Doing the same from other handsets, by dialling such codes as *#21# in each case gives the same result of eternal lchan usage, although some (more modern) phones seem to eventually timeout, releasing the channel while others do not. I connected numerous phones and did the same on each one and pretty soon I have a kind of DOS situation on the network in that SDCCH is at capacity.
The last log message resulting from the request is /openbsc/openbsc/src/libmsc/gsm_04_08.c:3586 Dispatching 04.08 message, pdisc=11 although strangely with one phone, this is followed shortly by: libosmocore/src/gsm/gsm0480.c:219 USSD Request is too short. openbsc/openbsc/src/libmsc/ussd.c:55 Unhandled SS so for that one phone, it would seem handle_rcv_ussd() is being called from gsm0408_dispatch()
I have been going through the code, basically adding more debug output to try to verify what is being called from where, and I also found the functionality in libosmocore such as gsm0480_decode_ss_request(), although this is not called at anytime from the nitb. This is an enormous project!
I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in gsm48_rx_mm_serv_req()
/* we will send a MM message soon */ conn->expire_timer_stopped = 1;
It would seem that we don't ever send this MM message.
It's not clear to me where I might try to check again on the status of this MM request, or if the problem is a lack of full implementation of these supplementary service requests.
Would anybody be interested in working on this with me?
Keith.
On 05 Jul 2016, at 16:49, Keith Whyte keith@rhizomatica.org wrote:
Hi All,
Hi!
I have been going through the code, basically adding more debug output to try to verify what is being called from where, and I also found the functionality in libosmocore such as gsm0480_decode_ss_request(), although this is not called at anytime from the nitb. This is an enormous project!
I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in gsm48_rx_mm_serv_req()
/* we will send a MM message soon */ conn->expire_timer_stopped = 1;
It would seem that we don't ever send this MM message.
It's not clear to me where I might try to check again on the status of this MM request, or if the problem is a lack of full implementation of these supplementary service requests.
Would anybody be interested in working on this with me?
sure. Can you extract that USSD query dialogue in a pcap file for us? The "expire timer stopped" is related to periodic LUs[1] and most likely not linked to anything you are seeing.
I don't know the SS codes by heart but your phone most likely queries for something like call barring, forwarding state and waits for an answer and we are happy to keep the channel open. Which means the "invokeId" is blocked in the phone.. which most likely means it will not try to use a different invokeId for the next call.
The right way is to reject it. But once we have the PCAP file we can see which message to reject (or returnResultLast to).
holger
[1] With periodic LU a phone needs to report every X interval to the system unless it had some form of contact in between. We use expire_timer_stopped to remember that we had contact and when the subscriber connection is gone/closed we update the DB with NOW + X interval (+ margin) as the time we want to expire the subscriber.
On 05/07/16 17:32, Holger Freyther wrote:
sure. Can you extract that USSD query dialogue in a pcap file for us? The "expire timer stopped" is related to periodic LUs[1] and most likely not linked to anything you are seeing.
I don't know the SS codes by heart but your phone most likely queries for something like call barring, forwarding state and waits for an answer and we are happy to keep the channel open. Which means the "invokeId" is blocked in the phone.. which most likely means it will not try to use a different invokeId for the next call.
Great, here are two pcap files. krzr.pcap is the motorola KRZR K3 as I switch aeroplane mode off and then on again. - You see interrogate SS right after the attach.
Nokia.cap is sending *#21# on a nokia 6070, following by powering off as it sits at the requesting.... screen
The right way is to reject it. But once we have the PCAP file we can see which message to reject (or returnResultLast to).
:-) Looking forward to seeing how this is done, after all the code analysis I did today, it'll be very rewarding!
thanks, k/
On 05 Jul 2016, at 19:48, Keith Whyte keith@rhizomatica.org wrote:
Nokia.cap is sending *#21# on a nokia 6070, following by powering off as it sits at the requesting.... screen
thank you. The ussd.c has "reject" calls in many of the paths but I don't see a response at all. I will start by adding your payload to the libosmocore ussd decoding test and see how much we handle that message and then move forward to use the Smalltalk BTS to simulate that CM Service Request + facility message.
holger
On 07 Jul 2016, at 14:39, Holger Freyther holger@freyther.de wrote:
Hi!
Nokia.cap is sending *#21# on a nokia 6070, following by powering off as it sits at the requesting.... screen
thank you. The ussd.c has "reject" calls in many of the paths but I don't see a response at all. I will start by adding your payload to the libosmocore ussd decoding test and see how much we handle that message and then move forward to use the Smalltalk BTS to simulate that CM Service Request + facility message.
can you please fetch this change https://gerrit.osmocom.org/503? The main issue is that our USSD/SS decoding does not distinguish between the ROS part (invoke, reject, return, returnLast) but is guessing about results or notifications based on having a "string". In case of interrogate SS there is no text..
feel free to either update the gerrit review or this ticket to see if this works. My BTS is still boxed so I did not try the resulting code myself.
holger
On 12 Jul 2016, at 18:03, Holger Freyther holger@freyther.de wrote:
Dear Keith,
can you please fetch this change https://gerrit.osmocom.org/503? The main issue is that our USSD/SS decoding does not distinguish between the ROS part (invoke, reject, return, returnLast) but is guessing about results or notifications based on having a "string". In case of interrogate SS there is no text..
feel free to either update the gerrit review or this ticket to see if this works. My BTS is still boxed so I did not try the resulting code myself.
time flies. The first patch identified the right lines, and approach but neither compiled nor was correct. Could you give it a try with the new one pushed to gerrit? It does compile and I will give it a try in a virtual environment now. :)
holger