osmo-hlr/tests/test_nodes.vty

162 lines
4.3 KiB
Plaintext
Raw Normal View History

OsmoHLR> ?
show Show running system information
list Print command list
exit Exit current mode and down to previous mode
help Description of the interactive help system
enable Turn on privileged mode command
terminal Set terminal line parameters
who Display who is on vty
logging Configure logging
no Negate a command or set its defaults
logp Print a message on all log outputs; useful for placing markers in test logs
subscriber Subscriber management commands
OsmoHLR> list
show version
show online-help
list
exit
help
enable
terminal length <0-512>
terminal no length
who
show history
logging enable
...
show logging vty
show alarms
show talloc-context (application|all) (full|brief|DEPTH)
show talloc-context (application|all) (full|brief|DEPTH) tree ADDRESS
show talloc-context (application|all) (full|brief|DEPTH) filter REGEXP
show stats
show stats level (global|peer|subscriber)
show asciidoc counters
show rate-counters
show gsup-connections
subscriber (imsi|msisdn|id|imei) IDENT show
show subscriber (imsi|msisdn|id|imei) IDENT
OsmoHLR> enable
OsmoHLR# ?
help Description of the interactive help system
list Print command list
write Write running configuration to memory, network, or terminal
show Show running system information
exit Exit current mode and down to previous mode
disable Turn off privileged mode command
configure Configuration from vty interface
copy Copy configuration
terminal Set terminal line parameters
who Display who is on vty
logging Configure logging
no Negate a command or set its defaults
logp Print a message on all log outputs; useful for placing markers in test logs
subscriber Subscriber management commands
OsmoHLR# list
help
...
exit
disable
configure terminal
copy running-config startup-config
show startup-config
show version
show online-help
terminal length <0-512>
terminal no length
who
show history
terminal monitor
terminal no monitor
logging enable
...
OsmoHLR# configure terminal
OsmoHLR(config)# ?
...
banner Set banner string
service Set up miscellaneous service
line Configure a terminal line
ctrl Configure the Control Interface
log Configure logging sub-system
stats Configure stats sub-system
hlr Configure the HLR
OsmoHLR(config)# list
help
...
exit
end
...
hlr
OsmoHLR(config)# hlr
OsmoHLR(config-hlr)# ?
...
euse Configure a particular External USSD Entity
no Negate a command or set its defaults
ussd USSD Configuration
ncss-guard-timeout Set guard timer for NCSS (call independent SS) session activity
store-imei Save the IMEI in the database when receiving Check IMEI requests. Note that an MSC does not necessarily send Check IMEI requests (for OsmoMSC, you may want to set 'check-imei-rqd 1').
subscriber-create-on-demand Make a new record when a subscriber is first seen.
OsmoHLR(config-hlr)# list
help
...
exit
end
gsup
database PATH
euse NAME
no euse NAME
ussd route prefix PREFIX internal (own-msisdn|own-imsi)
ussd route prefix PREFIX external EUSE
no ussd route prefix PREFIX
ussd default-route external EUSE
no ussd default-route
ncss-guard-timeout <0-255>
store-imei
no store-imei
subscriber-create-on-demand (no-msisdn|<3-15>) (none|cs|ps|cs+ps)
no subscriber-create-on-demand
OsmoHLR(config-hlr)# gsup
OsmoHLR(config-hlr-gsup)# ?
...
bind Listen/Bind related socket option
OsmoHLR(config-hlr-gsup)# list
...
bind ip A.B.C.D
OsmoHLR(config-hlr-gsup)# exit
OsmoHLR(config-hlr)# exit
OsmoHLR(config)# exit
OsmoHLR# configure terminal
OsmoHLR(config)# hlr
OsmoHLR(config-hlr)# store-imei
OsmoHLR(config-hlr)# gsup
OsmoHLR(config-hlr-gsup)# end
OsmoHLR# disable
OsmoHLR> enable
OsmoHLR# show running-config
Current configuration:
!
!
log stderr
...
logging level main notice
logging level db notice
logging level auc notice
logging level ss info
1/2: refactor: add and use lu_fsm, osmo_gsup_req, osmo_ipa_name These are seemingly orthogonal changes in one patch, because they are in fact sufficiently intertwined that we are not willing to spend the time to separate them. They are also refactoring changes, unlikely to make sense on their own. ** lu_fsm: Attempting to make luop.c keep state about incoming GSUP requests made me find shortcomings in several places: - since it predates osmo_fsm, it is a state machine that does not strictly enforce the order of state transitions or the right sequence of incoming events. - several places OSMO_ASSERT() on data received from the network. - modifies the subscriber state before a LU is accepted. - dead code about canceling a subscriber in a previous VLR. That would be a good thing to actually do, which should also be trivial now that we record vlr_name and sgsn_name, but I decided to remove the dead code for now. To both step up the LU game *and* make it easier for me to integrate osmo_gsup_req handling, I decided to create a lu_fsm, drawing from my, by now, ample experience of writing osmo_fsms. ** osmo_gsup_req: Prepare for D-GSM, where osmo-hlr will do proxy routing for remote HLRs / communicate with remote MSCs via a proxy: a) It is important that a response that osmo-hlr generates and that is sent back to a requesting MSC contains all IEs that are needed to route it back to the requester. Particularly source_name must become destination_name in the response to be able to even reach the requesting MSC. Other fields are also necessary to match, which were so far taken care of in individual numerous code paths. b) For some operations, the response to a GSUP request is generated asynchronously (like Update Location Request -> Response, or taking the response from an EUSE, or the upcoming proxying to a remote HLR). To be able to feed a request message's information back into the response, we must thus keep the request data around. Since struct osmo_gsup_message references a lot of external data, usually with pointers directly into the received msgb, it is not so trivial to pass GSUP message data around asynchronously, on its own. osmo_gsup_req is the combined solution for both a and b: it keeps all data for a GSUP message by taking ownership of the incoming msgb, and it provides an explicit API "forcing" callers to respond with osmo_gsup_req_respond(), so that all code paths trivially are definitely responding with the correct IEs set to match the request's routing (by using osmo_gsup_make_response() recently added to libosmocore). Adjust all osmo-hlr code paths to use *only* osmo_gsup_req to respond to incoming requests received on the GSUP server (above LU code being one of them). In fact, the same should be done on the client side. Hence osmo_gsup_req is implemented in a server/client agnostic way, and is placed in libosmo-gsupclient. As soon as we see routing errors in complex GSUP setups, using osmo_gsup_req in the related GSUP client is likely to resolve those problems without much thinking required beyond making all code paths use it. libosmo-gsupclient is hence added to osmo-hlr binary's own library dependencies. It would have been added by the D-GSM proxy routing anyway, we are just doing it a little sooner. ** cni_peer_id.c / osmo_ipa_name: We so far handle an IPA unit name as pointer + size, or as just pointer with implicit talloc size. To ease working with GSUP peer identification data, I require: - a non-allocated storage of an IPA Name. It brings the drawback of being size limited, but our current implementation is anyway only able to handle MSC and SGSN names of 31 characters (see struct hlr_subscriber). - a single-argument handle for IPA Name, - easy to use utility functions like osmo_ipa_name_to_str(), osmo_ipa_name_cmp(), and copying by simple assignment, a = b. Hence this patch adds a osmo_ipa_name in cni_peer_id.h and cni_peer_id.c. Heavily used in LU and osmo_gsup_req. Depends: libosmocore Id9692880079ea0f219f52d81b1923a76fc640566 Change-Id: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9
2019-11-20 01:36:45 +00:00
logging level mslookup notice
logging level lu notice
...
hlr
store-imei
database hlr_vty_test.db
gsup
bind ip 127.0.0.1
ussd route prefix *#100# internal own-msisdn
ussd route prefix *#101# internal own-imsi
end