According to https://tools.ietf.org/html/rfc5280 the pathlen information must be omitted if the CA boolean is false. In this case, since you never assert the CA to be true (hence default false) you must remove the pathlen information.

./gnmi_get -target_name "device_name" -xpath "/interfaces/interface[name=Ethernet16]" -target_addr "@IP:32767 -alsologtostderr -notls true

or

./gnmi_get -target_name "device_name" -xpath "/interfaces/interface[name=Ethernet16]" -target_addr "@IP:32767 -alsologtostderr -insecure true

or

(though notls and insecure was given i tried below) ./gnmi_get -target_name "device_name" -xpath "/interfaces/interface[name=Ethernet16]" -target_addr "@IP:32767 -alsologtostderr -notls true -insecure true -username ''username" -password "password"

all the above are giving same result as below

== GetRequest: path: < elem: < name: "interfaces"

elem: < name: "interface" key: < key: "name" value: "Ethernet16" >

encoding: JSON_IETF

F0204 13:12:23.567015 25776 gnmi_get.go:130] Get failed: rpc error: code = Unauthenticated desc = gNMI: get: metadata credentials not present

Am i sending anyparmeters wrong or doing anything wrong?

• Put CertificateId as part of GenerateCSRRequest msg, not LoadCertificateRequest msg.
• For Install and Rotate Addresses https://github.com/google/gnxi/issues/73

@larryleguo @samribeiro Hi When we try to build the gnmi project and gnmi target (I need gnmi target which is dependent to gnmi package) using Go modules or dep, we get an error like this:

pkg/gnmi/modeldata/gostruct/generated.go:71:63: undefined: ytypes.UnmarshalOpt pkg/gnmi/modeldata/gostruct/generated.go:81:25: too many arguments in call to ytypes.Unmarshal

Any ideas? It looks like there are some conflicts somewhere.

Hello,

I'm facing two issues with the xpath parsing both resulting in a "xpath component parse error".

It seems that '-' are not supported in the xpath when used for a key like in: --xpath '/state/chassis[chassis-number=1]/name/' It results in a "main.XpathError: xpath component parse error: chassis[chassis-number=1]".

It seems that '/' are stripped from the xpath, even when used as a key value like in: --xpath '/state/port[port_id=1/1/1]/statistics/out-packets' It results in a "main.XpathError: xpath component parse error: port[port_id=1"

(I cross-checked the xpath syntax with gnmi_get, which does not give errors on the xpaths described above)

Any ideas ?

Thanks, Oli

Related issue: #98 The strategy is to allow the target to pass in the Settings object which will tell the server what cases it should error on. These could be passed in as flags or otherwise when it's added to the CLI.

Also added proto definition and pb.go's

This is a temporary solution to back up perf experiment scripts for gateway machines. Gateway machines are intended to be non google machine. So, it is better to back up these scripts to github.

Hi guys, I have question regarding encoding of data. According to gNMI specification, section 2.3.1, I assumed, that when I will send get request to target, with a path which does not point to leaf node, then in response message will be one notification with one update message which value will be JSON encoded subtree located under this path.

But instead in response message I receive notification message with separate update message for each leaf node in that subtree. My question is, if I am missing something from official gNMI specification, or I had to setup gnxi target in some special way in order to receive whole subtree as JSON encoded value of one update message.

(M) gnmi_target/README.md -fix the run example (add missing '')

(M) README.md -update main README to include go version requirement.

(M) gnmi_target/openconfig-openflow.json -Update JSON to include a "state" container. (gnmi_get example fails without this). If this is not appropriate, alternative would be change the gnmi_get example to use a path of: "/system/openflow/controllers/controller[name=main]/connections/connection[aux-id=0]" (eg leave off the '/state/address')

The current client doesn't allow loading multiple certificates at once in a single install/rotate operation.

New argument: other_cas Comma separated list of filename prefixes that the client will use to the load the associated .pem and .key files

Usage:

./gnoi_cert -target_addr localhost:9339 -target_name 10.85.68.161 -logtostderr -ca device_rootCA.pem -ca_key device_rootCA.key -op provision -cert_id gnoi_demo \
-other_cas client_intermediateCA_B,client_intermediateCA_C,client_rootCA_B,client_rootCA_C,device_intermediateCA,device_rootCA -ip_address 10.85.68.161 -organization gnoi_dem -time_out 1m

There were a few things needed to get the orchestrator working so I implemented them. These include:

• Printing image build status to stdout

• Fixing run check for docker containers

• Fixing exec creation in the RunContainer stage

• Adding method to tar into /tmp and read into dockers CopyToContainer method

• Adding certs to containers on runtime

• Refactored formatting

• Fixing unit tests

• Send a single SubscribeRequest with many paths is sent.
• Do path inclusion comparison deal with sorted keys.
• Compare Subscription Update paths with requested paths.
• Check paths in Subscription tests.

https://pypi.org/project/pyangbind/

pyanbdind is a dependency of oc_config_validate. pyanbdind uses collections.MutableSequence, which after Python 3.10 is moved to collections.abc.MutableSequence

Until pyanbdind's code is updated, oc_config_validate can only work on Python 3.9

If you have Python 3.10, you can install and run oc_config_validate, after locally patching https://github.com/robshakir/pyangbind/pull/291

This happens only with an Arista (Mojo) AP so far:

SubscribeStream(/access-points/access-point[hostname=*]/radios/radio[id=1][operating-frequency=FREQ_2GHZ]/state) <= gRCP Error: <_MultiThreadedRendezvous of RPC that terminated with: status = StatusCode.UNKNOWN details = "EOF" debug_error_string = "UNKNOWN:Error received from peer ipv4:100.77.250.244:8080 {created_time:"2022-11-18T01:00:57.051639987-08:00", grpc_status:2, grpc_message:"EOF"}"

In the telemetry stream started with a gNMI Subscribe, the Target returns a gRPC error that contains a message "EOF". If the intention is to signal EndOfBatch, the gNMI specification tells how to do it (https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#3514-the-subscriberesponse-message)

oc_config_validate cannot deal with this gRCP error that is not an error, currently it is interpreted as if the stream was broken.

oc_config_validate can retry gNMI messages when assertions fail. This is to account for different delays in reflecting back configuration or state.

However, currently it is also retrying gNMI Set messages. This is not correct, as a Target needs only 1 successful SET message to do its job.

The retry mechanism must only apply to gNMI Get messages.

Hi,

We use gnxi with some of the libraries in our project and it seems that the dependencies used by gnxi are on the older side - especially cobra and viper- which uses the unsupported version of jwt github.com/dgrijalva/jwt-go

just ran go mod graph to see which ones could cause this issue and its clear its viper and cobra.

gnmi_set -target_addr 172.18.0.6:50052 -target_name 172.18.0.7 --insecure -password admin -username admin -update /interfaces/interface[name=ethernet-1/1]/subinterfaces/subinterface[index=1]/ipv6/addresses/address[ip='2001:192:58:3:1::1']/config/prefix-length:120

F0317 06:41:44.037370 24434 gnmi_set.go:72] error in parsing xpath "/interfaces/interface[name=ethernet-1/1]/subinterfaces/subinterface[index=1]/ipv6/addresses/address[ip=2001" to gnmi path

Seems like this was once broken before?