Yesterday I noticed that apparently we are unable to GET a variable with argument, e.g. in OsmoHLR get the ps-enabled status of a subscriber and passing the subscriber's IMSI along for the value we'd like to receive.
Experimenting a bit, I found that for GET commands, any tokens sent after the variable name are ignored, dropped on the floor and cause neither an error nor are evaluated.
With a tiny patch, we can make passing arguments to GET parameters optional:
https://gerrit.osmocom.org/4069
But notably, by adding some CTRL parsing tests I found some interesting behavior...
https://gerrit.osmocom.org/4067 https://gerrit.osmocom.org/4068
In OsmoHLR, such a status request is so far implemented as a SET, since SET takes an argument and also returns a result. See: https://gerrit.osmocom.org/4062 (patch obsolete after 4069)
For that particular set of commands in OsmoHLR:
enable-ps <IMSI> (WO) disable-ps <IMSI> (WO) status-ps <IMSI> (semantically RO, nevertheless a SET, so technically WO)
I thought it would also make sense to just have one variable for the whole lot, as in
subscriber-enable-ps <IMSI>,<val> (RW)
so that we reflect that single value with a single CTRL variable. After all, that's how the CTRL API appears to be intended: GET and SET commands on the same entity, instead of blowing up each variable by op * value range.
Or even a command to query and change various subscriber values:
subscriber <IMSI> <variable>[=<val>] [<variable>[=<val>] [...]] (RW)
e.g.
GET 1 subscriber 123456789087654 msisdn msc_nr imeisv reply: subscriber 123456789087654 msisdn=12345 msc_nr=1 imeisv=123456789abcdef
SET 1 subscriber 123456789087654 msisdn=54321 msc_nr=4 imeisv=fab123434843823 reply: OK or: "Cannot modify msc_nr, nothing changed" or: "Unknown subscriber parameter: xyz"
One step further would be to pick an identification trait from imsi, msisdn or imei...
GET 1 subscriber imsi=123456789087654 msisdn imeisv GET 1 subscriber msisdn=12345 imsi imeisv GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
(often a new subscriber in communal networks can easily find the phone's IMEI, where the IMSI is unknown, so queries like this would be useful in general)
Would this be too much of a monster command? Rather:
GET 1 subscriber-by-imsi 123456789087654 msisdn imeisv GET 1 subscriber-by-msisdn 12345 imsi imeisv GET 1 subscriber-by-imeisv 12345abcdef123 imsi msisdn
Comments welcome!
~N
On 26.09.2017 16:00, Neels Hofmeyr wrote:
One step further would be to pick an identification trait from imsi, msisdn or imei...
GET 1 subscriber imsi=123456789087654 msisdn imeisv GET 1 subscriber msisdn=12345 imsi imeisv GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
Can't we just skip parameters which do not have values and simply use
"GET 1 subscriber msisdn=12345"?
On Wed, Sep 27, 2017 at 10:34:21AM +0200, Max wrote:
On 26.09.2017 16:00, Neels Hofmeyr wrote:
One step further would be to pick an identification trait from imsi, msisdn or imei...
GET 1 subscriber imsi=123456789087654 msisdn imeisv GET 1 subscriber msisdn=12345 imsi imeisv GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
Can't we just skip parameters which do not have values and simply use
"GET 1 subscriber msisdn=12345"?
For GET 1 subscriber msisdn=12345 imsi imeisv my idea was to return imsi and imeisv values for subscriber selected by msisdn=12345.
But this superseded by another idea in another mail...
~N
On 26. Sep 2017, at 22:00, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Experimenting a bit, I found that for GET commands, any tokens sent after the variable name are ignored, dropped on the floor and cause neither an error nor are evaluated.
IIRC it was modeled like a property/sysctl. E.g.
kernel.sched_domain.cpu0.domain0.min_interval
one could say variable is "kernel.sched_domain" and parameter is "cpu0" or everything is encoded in the variable? I think we can have wildcards in the registration of commands.
does this make sense?
holger
On Wed, Sep 27, 2017 at 09:34:22PM +0800, Holger Freyther wrote:
IIRC it was modeled like a property/sysctl. E.g.
kernel.sched_domain.cpu0.domain0.min_interval
one could say variable is "kernel.sched_domain" and parameter is "cpu0"
There's indeed a lot more going on than I was aware of, thanks! I can send, with current libosmocore master:
GET 123 status-ps.imsi1234567898765
and it ends up in the status-ps command implementation. (The cmd->value remains empty, cmd->variable is "status-ps.imsi1234567898765")
Also we do have a concept of nesting CTRL nodes separated by dots in the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
I notice though that we do still have open doors for a lot of nonsense being sent to it without proper validation or error messages.
GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored
in effect is identical to:
GET 42 existing-variable
So we should probably enforce that there is no ignored nonsense...
Should we also enforce a numeric command ID?
GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
Going back to the OsmoHLR CTRL commands -- they are implemented in a way that doesn't match the CTRL interface ways. Let's collapse them.
SET enable-ps <IMSI> SET disable-ps <IMSI> SET status-ps <IMSI>
==>
SET subscriber.by-imsi.123456789098765.ps-enabled 1 SET subscriber.by-imsi.123456789098765.ps-enabled 0 GET subscriber.by-imsi.123456789098765.ps-enabled
We can also expand this later to things like
GET subscriber.by-imsi.123456789098765.status SET subscriber.by-imsi.123456789098765.msisdn 2345 GET subscriber.by-msisdn.2342.status SET subscriber.by-msisdn.2342.ps-enabled 0 GET subscriber.by-imei.987654321234565.imsi
yes?
We could leave the enable-ps, disable-ps, status-ps commands in place in case anyone is using it yet. I assume no-one is though.
~N
Hi Neels,
On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
Also we do have a concept of nesting CTRL nodes separated by dots in the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
correct.
I notice though that we do still have open doors for a lot of nonsense being sent to it without proper validation or error messages.
GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored
in effect is identical to:
GET 42 existing-variable
So we should probably enforce that there is no ignored nonsense...
I agree.
Should we also enforce a numeric command ID?
I'm not following here. Where would that numeric command ID comning from?
GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
this is also not intended, I'm quite sure.
Going back to the OsmoHLR CTRL commands -- they are implemented in a way that doesn't match the CTRL interface ways. Let's collapse them.
SET enable-ps <IMSI> SET disable-ps <IMSI> SET status-ps <IMSI>
indeed, this is not proper.
SET subscriber.by-imsi.123456789098765.ps-enabled 1 SET subscriber.by-imsi.123456789098765.ps-enabled 0 GET subscriber.by-imsi.123456789098765.ps-enabled
makes a lot of sense to me.
We can also expand this later to things like
GET subscriber.by-imsi.123456789098765.status SET subscriber.by-imsi.123456789098765.msisdn 2345 GET subscriber.by-msisdn.2342.status SET subscriber.by-msisdn.2342.ps-enabled 0 GET subscriber.by-imei.987654321234565.imsi
looks good!
We could leave the enable-ps, disable-ps, status-ps commands in place in case anyone is using it yet. I assume no-one is though.
I don't think we need to keep compatibility at this point.
-
Harald Welte -
Holger Freyther -
Max -
Neels Hofmeyr