Hi all
Another one not quite ready for a ticket, but maybe worth mentioning here.
A while back I noticed a phone of mine was holding channels open all the time. Turns out in does checks for call forwarding status and such on camping.
This got fixed in Legacy OpenBSC:
https://gerrit.osmocom.org/#/c/openbsc/+/503/
I noticed this, or something similar is back with the split setup.
Try dialing *#21# for example. or pick a code from here: http://www.geckobeach.com/cellular/secrets/gsmcodes.php
Then make a call. On some phones you can't, but if it does proceed, then hangup. On all the phones I tried you now have not only a lingering SDCCH, but also a TCH/F and on one phone, it doesn't ever go away, until you turn off the phone, or drop the BCCH.
sorry again for the lame bug report. I don't want to forget it and I can't pay it due attention in the coming days.
k/
Hi Keith,
On Thu, Oct 11, 2018 at 10:30:17PM +0200, Keith wrote:
Another one not quite ready for a ticket, but maybe worth mentioning here.
Why is it not ready? All that is missing to create a ticket is to include a pcap of Abis/A/GSUP from when you do the test...
A while back I noticed a phone of mine was holding channels open all the time. Turns out in does checks for call forwarding status and such on camping.
Was this before or after the external SS interface was introduced, particularly
commit 8a6ef55ec5838bdac3b5780bfc404c9b732d944f Author: Vadim Yanitskiy axilirator@gmail.com Date: Tue Jun 12 08:21:20 2018 +0700
?
In theory, all non-call related SS (NC_SS) should now be handled at the HLR, and the HLR should reject any of those.
The codes you refer to are, however, call related SS. I never looked into those much.
Please file an issue including protocol traces. tHanks.
On 12/10/18 08:59, Harald Welte wrote:
All that is missing to create a ticket is to include a pcap of Abis/A/GSUP from when you do the test...
You're right. I wanted to check a few more things.. to avoid questions like the below. I'll get to it when I can.. this ML post was just a note..
A while back I noticed a phone of mine was holding channels open all the time. Turns out in does checks for call forwarding status and such on camping.
Was this before or after the external SS interface was introduced, particularly
commit 8a6ef55ec5838bdac3b5780bfc404c9b732d944f
It was with legacy. I haven't done any bisect test on osmo-msc.
In theory, all non-call related SS (NC_SS) should now be handled at the HLR, and the HLR should reject any of those.
The codes you refer to are, however, call related SS. I never looked into those much.
There is some log output on the HLR.
Please file an issue including protocol traces. tHanks.
Yep..
On Thu, Oct 11, 2018 at 10:30:17PM +0200, Keith wrote:
A while back I noticed a phone of mine was holding channels open all the time. Turns out in does checks for call forwarding status and such on camping.
This got fixed in Legacy OpenBSC:
https://gerrit.osmocom.org/#/c/openbsc/+/503/
I noticed this, or something similar is back with the split setup.
Try dialing *#21# for example. or pick a code from here: http://www.geckobeach.com/cellular/secrets/gsmcodes.php
Then make a call. On some phones you can't, but if it does proceed, then hangup. On all the phones I tried you now have not only a lingering SDCCH, but also a TCH/F and on one phone, it doesn't ever go away, until you turn off the phone, or drop the BCCH.
^ I think even that, even without a pcap, would qualify as a non-lame new issue, easier to track than a loose mail thread. Fear not, if an issue turns out lame, we can always Reject it.
I do that all the time: create a vague issue, add info later; possibly see my own failure to understand what was going on, and drop them.
~N
On 12/10/18 12:39, Neels Hofmeyr wrote:
^ I think even that, even without a pcap, would qualify as a non-lame new issue, easier to track than a loose mail thread. Fear not, if an issue turns out lame, we can always Reject it.
:) I guess after "agonizing" over whether to make a ticket or an ML post about the MSC volatile state issue, I was all out of creativity for issue titles. perfectionism! it's a curse. And now.. here I am wasting productive time writing to the ML.. argghhh.
:)
k/
-
Harald Welte -
Keith -
Neels Hofmeyr