methods BadUnsupported

[AiyionPrime]

I created a server using the ServerBuilder and try to run add_methods() from the demo-server sample - while this works fine, I cannot run the methods using uaexpert.
Is this expected behaviour?

Sadly my only output is:
Call failed with status "BadServiceUnsupported" in uaexpert.
I do not receive Errors in the log of cargo run.

The only thing I see there (but upon browsing of nodes in general) is
WARN opcua_server::node_manager::memory::diagnostics] Unknown node...
occasionally.

Can I somehow raise the loglevel further, or is there a server setting I might have missed?
I did not touch the contents of add_methods.

I'll try to setup an example project of my problem.

[oroulet]

logging is not great in that part of the code. so not surprise you do not get any logging.
calling a method on demo server from uaexpert work I suppose?

[AiyionPrime]

That's a different story... Building the async-opcua repo fails for me in the fuzzing section...
But I've built a minimal demo repo here:

https://github.com/AiyionPrime/programmatic_methods

[AiyionPrime]

I opened an issue for the fuzz problem, but that's not to urgent for me right now :D

[AiyionPrime]

[AiyionPrime]

I reduced the server.conf to this where it still works.

application_name: OPC UA Sample Server
application_uri: urn:async-opcua-Sample-Server
product_uri: urn:async-opcua-Sample-Server-Testkit
create_sample_keypair: true
certificate_path: own/cert.der
private_key_path: private/private.pem
certificate_validation:
  trust_client_certs: false
  check_time: true
pki_dir: ./pki
# discovery_server_url: opc.tcp://localhost:4840/UADiscovery
tcp_config:
  hello_timeout: 5
  host: localhost
  port: 4855
limits:
performance:
  single_threaded_executor: false
user_tokens:
discovery_urls:
- opc.tcp://localhost:4855/
default_endpoint: null
endpoints:
  none:
    path: /
    security_policy: None
    security_mode: None
    security_level: 0
    password_security_policy: null
    user_token_ids:
    - ANONYMOUS

[einarmo]

Your issue is that by default node managers are tied to namespaces. It really is not obvious so I can see how you got confused. Maybe we can log a warning somehow? I'm not sure how easy it is.

So when you send a Call request to your server, it hits the first node manager that says that it owns the node you call. Node ownership is decided by namespace, so it hits the first node manager with the namespace urn:MethodServer.

This happens to be the diagnostic node manager, i.e. the node manager for server-specific metadata like diagnostics, auditing (TBI), etc. This node manager doesn't support methods at all, so you get BadServiceUnsupported.

To fix, just use a different value for your node manager and application_uri. I'll note this in the sample. Not sure if we really can catch it, since you can have servers where it's deliberate, or node managers that aren't tied to a specific namespace like this.

[AiyionPrime]

No, it was not my intention to let them collide, you're absolutely right. Thanks for spotting it.

[AiyionPrime]

@einarmo Call me interested -.-'
If I was asking for trouble. As in: I want my nodes to indeed land in namespace 1,
how would one do this in this specific case?

[einarmo]

You need to not have the diagnostic node manager at all, I think. So, on the builder, call without_node_managers to remove the default node managers, then re-add the core node manager (you do generally need that one):

.with_node_manager(
    InMemoryNodeManagerBuilder::new(
        CoreNodeManagerBuilder,
    ),
)

THEN you can add your node manager.

Technically you could add the diagnostic node manager after that. If you give it a different namespace it'll end up as namespace index 2 or something like that. If you give it the same namespace you may still have issues. I'm not entirely sure, actually.

I haven't actually tried this, but it should work. If you don't define the diagnostic node manager some nodes you might expect will be missing, but your server will be mostly compliant still, I think. The diagnostic node manager only defines the metadata nodes for each namespace. You can define those yourself if you want.

[einarmo]

The fact that you can do this does mean that the core node manager is optional. Things may not work very well if it's missing, but that's the default if you don't enable the generated_address_space feature.

[AiyionPrime]

Thanks man, I owe you :D

I tested it and removing the NM, adding ours and reading the CoreNM does indeed work.