Ruckus Access Point Controller decoders

[Gerald muchuku]

Hi team, 

I am having a problem figuring out decoders for a Ruckus Access Point that is forwarding logs to Wazuh using syslog.
Below is a sample of the logs as received via syslog:
2026-03-24T13:37:04+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job[troubleshooting_timer] at 1774359424...
2026-03-24T13:37:04+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job at 1774359424...Done
2026-03-24T13:37:04+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:04+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:05+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:05+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:06+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:06+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:07+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:07+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-08-04T10:12:09+00:00 dd43-0404-2039-0051 mpe_sd: <186> [ DEBUG] channe 7 module_powerdown#015
2026-03-24T13:37:08+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:08+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:09+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:09+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job[radsecproxy_timer] at 1774359430...
2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job at 1774359430...Done
2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job[user auth attempt_hash_autoexpire] at 1774359430...
2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job at 1774359430...Done
2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job[station auth attempt_hash_autoexpire] at 1774359430...
2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job at 1774359430...Done
2026-08-04T10:12:11+00:00 dd43-0404-2039-0051 mpe_sys: <187> [ DEBUG] channel 2 warning resent at command is AT+CPIN?#015
2026-03-24T13:37:10+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:10+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:35+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:35+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-08-04T10:12:37+00:00 dd43-0404-2039-0051 mpe_sd: <221> [ DEBUG] channe 3 module_powerup retry 3#015
2026-03-24T13:37:36+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:36+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-08-04T10:12:39+00:00 dd43-0404-2039-0051 mpe_sd: <222> [ DEBUG] channe 1 restart the simcard#015
2026-08-04T10:12:39+00:00 dd43-0404-2039-0051 mpe_sd: <223> [ DEBUG] channe 4 restart the simcard#015
2026-08-04T10:12:39+00:00 dd43-0404-2039-0051 mpe_sd: <224> [ DEBUG] channe 6 restart the simcard#015
2026-03-24T13:37:37+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:37+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:38+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:38+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:39+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:39+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-03-24T13:37:40+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
2026-03-24T13:37:40+00:00 192.168.0.3 radsecproxy[1188]: connecttcphostlist: failed
2026-08-04T10:12:42+00:00 dd43-0404-2039-0051 mpe_sd: <225> [ DEBUG] channe 5 restart the simcard#015
2026-03-24T13:37:41+00:00 192.168.0.3 syslog: pid=554, doJobEx():worker: action:[cleanup-response], Start.
2026-03-24T13:37:41+00:00 192.168.0.3 syslog: eventd_to_syslog():User[ac:12:03:8b:b8:d9] disconnects from WLAN[KAR] at AP[RuckusAP-RECE@d0:4f:58:14:21:90]
2026-03-24T13:37:41+00:00 192.168.1.38 syslog: lwapp_get_sta_stats IEEE80211_RUCKUS_GET_STA_STATS=163 ioctl failed
2026-03-24T13:37:41+00:00 192.168.0.3 syslog: eventd_to_syslog():User[ac:12:03:8b:b8:d9] leave WLAN[KAR] at AP[RuckusAP-RECE@d0:4f:58:14:21:90] with Session Time[506.36 sec] RX Bytes[3993524] TX Bytes[4242511]
2026-03-24T13:37:41+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed

Kindly assist in writing decoders and rules that will work for this.

Regards,

Gerald Muchuku.

[hasitha.u...@wazuh.com]

Hi Gerald

Please allow me some time; I’m currently looking into this and will get back to you with an update as soon as possible.

[Gerald muchuku]

Hi Hasitha,

Thank you

Regards,

Gerald.

[hasitha.u...@wazuh.com]

Hi Gerald,

I tested the sample logs you shared.

For this log:

2026-03-24T13:37:04+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job[troubleshooting_timer] at 1774359424...

the predecoder identifies the program_name as syslog.

For this log:

2026-03-24T13:37:10+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed

the program_name is identified as radsecproxy.

Because of that, could you please confirm how these logs are being collected?

For example, are you:

1. forwarding the logs to a file through rsyslog on the endpoint and then collecting that file with the Wazuh agent, or

2. sending the logs directly to the Wazuh manager using the manager syslog listener?

If you are collecting the logs through rsyslog and then using the Wazuh agent, I would suggest using the out_format option in the localfile configuration. This adds a custom prefix before the log is sent to the manager, which makes it easier to build a parent decoder and avoid issues caused by different program_name values.

For example, on the agent side:

1. <localfile>
2.  <log_format>syslog</log_format>
3.  <location>/root/test.log</location>
4.  <out_format>Ruckus: $(log)</out_format>
5. </localfile>

Then the logs forwarded to the Wazuh manager would look like this:

Ruckus: 2026-03-24T13:37:38+00:00 192.168.0.3 radsecproxy[1188]: connecttoserver: connect failed
Ruckus: 2026-03-24T13:37:10+00:00 192.168.0.3 syslog: pid=554, jobServiceFunc():worker: Executing job at 1774359430...Done

With that, you can create a parent decoder like this:

1. <decoder name="ruckus">
2.  <prematch>^Ruckus:</prematch>
3. </decoder>
4. <decoder name="ruckus-fields">
5.   <parent>ruckus</parent>
6.   <regex>(\d+-\d+-\S+:\d+:\S+:\d+)\s(\d+.\d+.\d+.\d+)\s(\S+)[\d+]|(\d+-\d+-\S+:\d+:\S+:\d+)\s(\d+.\d+.\d+.\d+)\s(\S+):</regex>
7.   <order>log_time, ip ,program</order>
8. </decoder>
9.  
10. <decoder name="ruckus-fields">
11.   <parent>ruckus</parent>
12.   <regex>\d+-\d+-\S+:\d+:\S+:\d+\s\d+.\d+.\d+.\d+\s\S+[\d+]:(\.+)|\d+-\d+-\S+:\d+:\S+:\d+\s\d+.\d+.\d+.\d+\s\S+:\.+, (\.+)</regex>
13.   <order>message</order>
14. </decoder>

This approach is helpful when both log types need to be matched under the same custom decoder flow.

For more details, please refer to these guides:

• Custom Decoder
• Decoder syntax
• Custom decoder and rule creation blog

Please share a bit more about how the logs are being collected, and then I can help you refine the decoder further.

[Gerald muchuku]

Thank you for the reply Hasitha,

The logs are being sent directly to the wazuh manager via syslog from the Ruckus Access Point with IP address 192.168.0.3

Regards,

Gerald Muchuku.

[Kafleen Qalmar]

Hello

[Gerald muchuku]

Hello Kafleen,

I have still not gotten any working decoders. Kindly assist

Regards,

Gerald Muchuku.

[hasitha.u...@wazuh.com]

Hi Gerald,

I have created a custom decoder for capturing logs. You can place these decoders /var/ossec/etc/decoders/local_decoder.xml in this file, if you already have custom rules place in this custom decoder creation file, please replace them with this.

1. <decoder name="ruckus">
2.   <program_name>radsecproxy|syslog</program_name>
3. </decoder>
4.  
5. <!-- Child decoder: Extracts custom fields only -->

1. <decoder name="ruckus-fields">
2.   <parent>ruckus</parent>

1.   <regex>pid=\d+, (\.+)|(\.+)</regex>
2.   <order>message</order>
3. </decoder>

After that, you can add this custom rule to /var/ossec/etc/rules/local_rules.xml file to generate alerts.

1. <group name="ruckus">
2.  
3.   <rule id="400200" level="3">
4.     <decoded_as>ruckus</decoded_as>
5.     <description>Ruckus: $(message)</description>
6.   </rule>
7.  
8. </group>

After adding the custom decoders and rule you need to restart the Wazuh manager to apply changes.
systemctl restart wazuh-manager

If the logs still won't show up on the dashboard, and it's already written to this file /var/ossec/logs/alerts/alerts.json file, then please share the sample logs from archives.json logs.
By default, archive logs are disabled due to high storage consumption. Edit the /var/ossec/etc/ossec.conf file and add this:

1. <ossec_config>
2. <global>
3. <logall_json>yes</logall_json>
4. </global>
5. </ossec_config>

Save the file, then restart the manager again: systemctl restart wazuh-manager

This will log all events to /var/ossec/logs/archives/archives.json, so you can see everything your manager is picking up.

Check the Archive Logs: Now, let’s look for Ruckus-related logs in the archive: cat /var/ossec/logs/archives/archives.json | grep keyword

Replace keyword with sample log unique content.

Warning Keeping <logall_json>yes</logall_json> on can fill up your disk fast! Once you’re done troubleshooting, set it back to no in /var/ossec/etc/ossec.conf and restart the manager: systemctl restart wazuh-manager

Once you verify logs receiving to the archives.json logs, which means logs reaching the manager, but not showing in the dashboard, can be a common issue if the decoders and rules are not matched by default, therefore you can share sample logs from the archives.json logs so then I can replicate on my end and I can share the sample decoders and rules based on the logs.

Because in the archives.json logs, we can see the field full_log: "actual log sample", which is the one being parsed by analysis. Therefore, please share the sample logs so we can assist further.

Let me know the update on this, so I can check further. Thanks!

[Gerald muchuku]

Hi Hasitha,

The provided decoders worked. The Ruckus AP logs are now visible on the Wazuh Dashboard.

Thank you very much.

Regards,

Gerald Muchuku.

[hasitha.u...@wazuh.com]

Hi Gerald,

I am glad that decoders are working and you are able to see the logs on the dashboard. Thanks!