Hi Ahnaf, How to use the CTRL interface: The syntax of CTRL commands is explained in the user manuals for each application. For example, see https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf chapter "Control interface" for CTRL commands supported by osmo-hlr, and chapter "Osmocom Control Interface" for a general definition. Interaction works pretty much identical to VTY, just use a different port: https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers See "Control interface" entries to find out the proper ports. A python implementation and cmdline tool is osmo_interact_ctrl.py in https://gitea.osmocom.org/cellular-infrastructure/osmo-python-tests/src/branch/master/scripts (shares a lot of code with osmo_interact_vty.py)
Project naming: May I ask, generally: if you write "Osmocom GUI", I'd expect that it configures / interacts with a complete network. Does it only interact with osmo-hlr? Then maybe you could call it "OsmoHLR GUI"? HLR db: The SQL database schema is pretty much guaranteed to change with newer versions of OsmoHLR. The schema is pretty self-explanatory, just run 'sqlite3 ./hlr.db .dump' You may require to stop the osmo-hlr process to access the hlr.db. So you should not act directly on the OsmoHLR database, when it can be avoided. That said, when dealing with huge volumes of subscribers, interacting with the sqlite3 db can be the only practical option. Using SQL to query a complete subscriber database can be a very good idea for a GUI application, because SQL is a generic tool for this task and (can be) very efficient. When using SQL to *manipulate* the HLR database, you should really know what you are doing -- rather use CTRL or VTY for that. CTRL vs VTY: I hope I am not infringing here, but, my *personal* *opinion* is that often, interacting via VTY is a pretty ok alternative to using CTRL. Many VTY commands are as stable as the CTRL interface; for example, I do not expect the VTY commands that manipulate a subscriber in OsmoHLR to change in a non-compatible way. Our own test suite does a lot of VTY interaction. Very often, the alternatives are: implementing new CTRL commands in C vs. just "for now" using the VTY that is already implemented, and usually "more alive". The downsides to using the VTY: - you don't get a clear "OK" / "ERROR" response from the VTY. - the osmocom project does NOT guarantee that the output the VTY produces remains the same over time. If you parse VTY output, you may very well need to adjust your program over time / keep track of what version you are compatible with. These are serious drawbacks. So, choose wisely :) ~N
