This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deYesterday 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 -- - Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170926/294acae9/attachment.bin>