Project

General

Profile

Actions

Bug #2688

open

CTRL iface: make rate_ctr request parser more strict

Added by pespin over 6 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
libosmocore
Target version:
-
Start date:
11/28/2017
Due date:
% Done:

50%

Spec Reference:

Description

$ ./osmo_interact_ctrl.py --host localhost --port 4251
GET 1 rate_ctr.per_hour.sgsn
ERROR 1 Counter group must be of name.index form e. g. e1inp.0

GET 1 rate_ctr.per_hour.sgsn.*
GET_REPLY 1 rate_ctr.per_hour.sgsn.* llc:dl_bytes 4719;llc:ul_bytes 6058;llc:dl_packets 45;llc:ul_packets 47;gprs:attach_requested 1;gprs:attach_accepted 1;gprs:attach_rejected 0;gprs:detach_requested 0;gprs:detach_acked 0;gprs:routing_area_requested 2;gprs:routing_area_requested 2;gprs:routing_area_requested 0;pdp:activate_requested 1;pdp:activate_rejected 0;pdp:activate_accepted 1;pdp:request_activated 0;pdp:request_activate_rejected 0;pdp:modify_requested 0;pdp:modify_accepted 0;pdp:dl_deactivate_requested 0;pdp:dl_deactivate_accepted 0;pdp:ul_deactivate_requested 0;pdp:ul_deactivate_accepted 0;

GET 1 rate_ctr.per_hour.sgsn.llc
GET_REPLY 1 rate_ctr.per_hour.sgsn.llc llc:dl_bytes 4719;llc:ul_bytes 6058;llc:dl_packets 45;llc:ul_packets 47;gprs:attach_requested 1;gprs:attach_accepted 1;gprs:attach_rejected 0;gprs:detach_requested 0;gprs:detach_acked 0;gprs:routing_area_requested 2;gprs:routing_area_requested 2;gprs:routing_area_requested 0;pdp:activate_requested 1;pdp:activate_rejected 0;pdp:activate_accepted 1;pdp:request_activated 0;pdp:request_activate_rejected 0;pdp:modify_requested 0;pdp:modify_accepted 0;pdp:dl_deactivate_requested 0;pdp:dl_deactivate_accepted 0;pdp:ul_deactivate_requested 0;pdp:ul_deactivate_accepted 0;

GET 1 rate_ctr.per_hour.sgsn.llc:dl_bytes
GET_REPLY 1 rate_ctr.per_hour.sgsn.llc:dl_bytes llc:dl_bytes 4719;llc:ul_bytes 6058;llc:dl_packets 45;llc:ul_packets 47;gprs:attach_requested 1;gprs:attach_accepted 1;gprs:attach_rejected 0;gprs:detach_requested 0;gprs:detach_acked 0;gprs:routing_area_requested 2;gprs:routing_area_requested 2;gprs:routing_area_requested 0;pdp:activate_requested 1;pdp:activate_rejected 0;pdp:activate_accepted 1;pdp:request_activated 0;pdp:request_activate_rejected 0;pdp:modify_requested 0;pdp:modify_accepted 0;pdp:dl_deactivate_requested 0;pdp:dl_deactivate_accepted 0;pdp:ul_deactivate_requested 0;pdp:ul_deactivate_accepted 0;
GET 1 rate_ctr.per_hour.sgsn.llc.dl_bytes

Related issues

Related to libosmocore - Bug #4443: CTRL interface blocks wildcard in rate_ctrNew03/08/2020

Actions
Actions #1

Updated by msuraev over 6 years ago

What does request for rate_ctr.* returns?

Actions #2

Updated by msuraev over 6 years ago

Unable to reproduce with osmo-bsc:

./osmopy/osmo_ctrl.py -d localhost  -g 'rate_ctr.*'
Got message: GET_REPLY 3150373144906480423 rate_ctr.* e1inp.0;bsc.0;msc.0;
./osmopy/osmo_ctrl.py -d localhost  -g 'rate_ctr.abs.msc.0.call:mo_setup'
Got message: GET_REPLY 3344138407237695467 rate_ctr.abs.msc.0.call:mo_setup 0
./osmopy/osmo_ctrl.py -d localhost  -g 'rate_ctr.abs.msc.*'
Got message: GET_REPLY 4460198632825467370 rate_ctr.abs.msc.* loc_update_type:attach 0;loc_update_type:normal 0;loc_update_type:periodic 0;loc_update_type:detach 0;loc_update_resp:failed 0;loc_update_resp:completed 0;sms:submitted 0;sms:no_receiver 0;sms:delivered 0;sms:rp_err_mem 0;sms:rp_err_other 0;sms:deliver_unknown_error 0;call:mo_setup 0;call:mo_connect_ack 0;call:mt_setup 0;call:mt_connect 0;call:active 0;call:complete 0;call:incomplete 0;
Actions #3

Updated by pespin over 6 years ago

GET 1 rate_ctr.*
GET_REPLY 1 rate_ctr.* sgsn:pdpctx.5;sgsn:mmctx.2320090910;bssgp:bss_ctx.1800;bssgp:bss_ctx.0;ns:nsvc.1800;sgsn.0;ns:nsvc.65534;
Actions #4

Updated by msuraev over 6 years ago

The request was incorrect:

./osmopy/osmo_ctrl.py -d localhost -p 4251 -g 'rate_ctr.abs.sgsn.0.llc:ul_bytes'
Got message: GET_REPLY 158669082903443187 rate_ctr.abs.sgsn.0.llc:ul_bytes 0

We've got to update docs to clarify this.

Actions #5

Updated by pespin over 6 years ago

Yes indeed, it seems I had to pass that index after "sgsn": sgsn.0

GET 1 rate_ctr.abs.sgsn.llc:dl_bytes
GET_REPLY 1 rate_ctr.abs.sgsn.llc:dl_bytes llc:dl_bytes 4769;llc:ul_bytes 6300;llc:dl_packets 47;llc:ul_packets 51;gprs:attach_requested 1;gprs:attach_accepted 1;gprs:attach_rejected 0;gprs:detach_requested 0;gprs:detach_acked 0;gprs:routing_area_requested 4;gprs:routing_area_requested 4;gprs:routing_area_requested 0;pdp:activate_requested 1;pdp:activate_rejected 0;pdp:activate_accepted 1;pdp:request_activated 0;pdp:request_activate_rejected 0;pdp:modify_requested 0;pdp:modify_accepted 0;pdp:dl_deactivate_requested 0;pdp:dl_deactivate_accepted 0;pdp:ul_deactivate_requested 0;pdp:ul_deactivate_accepted 0;

GET 1 rate_ctr.abs.sgsn.0.llc:dl_bytes
GET_REPLY 1 rate_ctr.abs.sgsn.0.llc:dl_bytes 4769
However, I don't know why using "sgsn" without ".0" returns all of them actually. I would expect one of the following behaviour:
  • GET 1 rate_ctr.abs.sgsn.* -> should print the prefix "0" somehow before printing all the variables containing it, or otherwise fail.
  • GET 1 rate_ctr.abs.sgsn.llc:dl_bytes -> should fail as no ".0" prefix has been given.
  • GET 1 rate_ctr.abs.sgsn.llc -> should fail as no ".0" prefix has been given.
Actions #6

Updated by msuraev over 6 years ago

Gerrit 5076 has documentation update which should clarify this.

Actions #7

Updated by msuraev over 6 years ago

  • Project changed from OsmoSGSN to Cellular Network Infrastructure
  • Status changed from New to In Progress
  • Assignee changed from 4368 to msuraev
  • % Done changed from 0 to 50
Actions #8

Updated by pespin over 6 years ago

The doc patch is fine, but the parsing is still outputing nonsense if the path is not correctly specified.

Actions #9

Updated by msuraev over 6 years ago

  • Status changed from In Progress to Feedback
  • Assignee changed from msuraev to pespin

How should output look like instead?

Actions #10

Updated by pespin over 6 years ago

  • Assignee changed from pespin to msuraev

I already posted what's wrong:

However, I don't know why using "sgsn" without ".0" returns all of them actually. I would expect one of the following behaviour:

* GET 1 rate_ctr.abs.sgsn.* -> should print the prefix "0" somehow before printing all the variables containing it, or otherwise fail. Or print all the prefixes available.
* GET 1 rate_ctr.abs.sgsn.llc:dl_bytes -> should fail as no ".0" prefix has been given.
* GET 1 rate_ctr.abs.sgsn.llc -> should fail as no ".0" prefix has been given.

Also, if you try to run "GET 1 rate_ctr.abs.sgsn.llc:dl_bytes", then it could be known that the index is missing so an error stating it can be provided.

Actions #11

Updated by msuraev over 6 years ago

  • Assignee deleted (msuraev)
Actions #12

Updated by msuraev over 6 years ago

  • Project changed from Cellular Network Infrastructure to libosmocore
  • Subject changed from CTRL iface: unable to fetch one specific rate_ctr to CTRL iface: make rate_ctr request parser more strict

That's possible by rewriting get_rate_ctr() but I don't see much gain: the documented cases work as expected. The fact that you can get some extra info using undocumented request is just minor annoyance.

Actions #13

Updated by msuraev over 6 years ago

  • Status changed from Feedback to New
Actions #14

Updated by pespin over 6 years ago

Minor annoyance which can break your scripts in weird ways by receiving data through undocumented behaviour instead of returning an error.

Actions #15

Updated by msuraev over 6 years ago

pespin wrote:

can break your scripts in weird ways by receiving data through undocumented behaviour

Scripts relying on undocumented behavior are expected to fail :)
Anyway, feel free to fix it.

Actions #16

Updated by neels over 6 years ago

BTW, seeing output like

GET_REPLY 1 rate_ctr.abs.sgsn.llc:dl_bytes llc:dl_bytes 4769;llc:ul_bytes 6300;llc:dl_packets 47;llc:ul_packets 51;gprs:attach_requested 1;gprs:attach_accepted 1;gprs:attach_rejected 0;gprs:detach_requested 0;gprs:detach_acked 0;gprs:routing_area_requested 4;gprs:routing_area_requested 4;gprs:routing_area_requested 0;pdp:activate_requested 1;pdp:activate_rejected 0;pdp:activate_accepted 1;pdp:request_activated 0;pdp:request_activate_rejected 0;pdp:modify_requested 0;pdp:modify_accepted 0;pdp:dl_deactivate_requested 0;pdp:dl_deactivate_accepted 0;pdp:ul_deactivate_requested 0;pdp:ul_deactivate_accepted 0;

makes me want to move back to newline-separated rate ctr reports. Sure the CTRL is for machine interaction, but there's no point in making it less readable for no benefit, both \n and ; are just a single character.

Actions #17

Updated by msuraev over 6 years ago

I'd rather stick with ; to avoid questions raised in https://gerrit.osmocom.org/#/c/4068/

Actions #18

Updated by laforge about 4 years ago

  • Related to Bug #4443: CTRL interface blocks wildcard in rate_ctr added
Actions #19

Updated by laforge almost 3 years ago

  • Category set to libosmocore
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)