[BUG] Crash in 'static_checks:mikrotik_bgp' after update to v3.3.0 - missing BGP sessions

[Widmo]

Describe the bug
After updating the MikroTik plugin to version 3.3.0, I am experiencing issues with BGP monitoring.

1. Not all BGP sessions are discovered (I have 6 sessions total, but only 2 are shown).
2. One of the visible sessions is stuck in CRIT state with "No BGP state information available", even though the session is up.
3. I cannot modify parameters for this plugin in WATO/Setup because it triggers an internal error (Crash).

To Reproduce
Steps to reproduce the behavior:

1. Update plugin to version 3.3.0.
2. Remove and re-add the MikroTik host (as per update instructions).
3. Go to 'Setup' -> 'Services' -> 'Service monitoring rules' -> 'MikroTik BGP'.
4. Try to modify any rule or view the parameters.
5. See error: Internal error: 'static_checks:mikrotik_bgp'

Expected behavior
All established BGP sessions should be discovered and monitoring rules should be editable without crashing.

Screenshots / Error Log
Crash ID: 068d8ea4-0e3d-11f1-987e-005056a9d47e

Error message:

Internal error: 'static_checks:mikrotik_bgp'
An internal error occurred while processing your request...

Example of incorrect service output:

• OK BGP Peer 1: Established with ASxxxxx (IPv6 address)
• CRIT BGP Peer 2: No BGP state information available (Session is actually UP)

Additional context

• Checkmk version: 2.4.0p21
• Plugin version: 3.3.0
• I have already tried uninstalling and reinstalling the plugin, but the issue persists.

[Widmo]

Update / Root Cause Analysis:
I ran the special agent manually and found the root cause. The agent fetches all sessions correctly, but the check plugin parses the names incorrectly. It truncates the BGP peer name at the first space.

Agent output:
<<<mikrotik_bgp>>>
name nask ipv4 peer 2
...
name nask ipv4 peer 1
...
name equnix ipv4 peer 1

Instead of creating separate services like "BGP nask ipv4 peer 1", the plugin groups them into just two services: "BGP nask" and "BGP equnix".
The "BGP nask" service goes CRIT because the last parsed item for this group (name nask ipv6 peer 2) is not established, overwriting the state of the established sessions.

[Widmo]

Update 2:
Agent bug (Disabled sessions): Disabled BGP connections are fetched by the agent, but the disabled flag is not passed to the output. As a result, disabled sessions trigger a CRIT ("No BGP state information available") instead of the expected WARN.