Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NewSession:SendHello prior to ReceiveHello is better #88

Open
lyonsdpy opened this issue May 31, 2019 · 2 comments
Open

NewSession:SendHello prior to ReceiveHello is better #88

lyonsdpy opened this issue May 31, 2019 · 2 comments
Labels

Comments

@lyonsdpy
Copy link

I had tested this tool on several type of devices,like juniper、huawei、cisco、h3c,
bug there's a problem with h3c devices
there have a half of change that the read() hangs forever
because go-netconf NewSession() handle send hello after receive, this may cause the first data request was send follow closely with hello. then device receive hello and handle it and drop the data request.(because the hello package does not processing completed )
So I interchange the posstion of the hello send and receive. It work well

@kpostrup
Copy link

I am experiencing the same issue, using a Huawei device.
The first Exec() request would take up to 5 seconds to complete while subsequent requests would execute immediately. In a small demo application, where I would execute the following get-config request, it would take almost 7 seconds to complete,

<get-config><source><running/></source><filter>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>%s</name>
    </interface>
  </interfaces>
</filter></get-config>

Running the same in Python using the ncclient library, would take below 2 seconds.

I have only shortly tested this, by doing as @lyonsdpy suggested, switching the order of t.SendHello() and t.ReceiveHello() and it solves the delay I'm experiencing. All the commands are now executed quickly without delay.

kpostrup added a commit to kpostrup/go-netconf that referenced this issue Mar 24, 2020
@nemith
Copy link
Collaborator

nemith commented Jul 22, 2022

This is against the standard: https://datatracker.ietf.org/doc/html/rfc6241#section-8.1

Each peer sends its element simultaneously as soon as the connection is open. A peer MUST NOT wait to receive the capability set from the other side before sending its own set.

@kpostrup Your change looks good. Can you cut a PR? Your change is correct.

@nemith nemith added the bug label Jul 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants