Omada Controller "Remote Logging" seems broken

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Omada Controller "Remote Logging" seems broken

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Omada Controller "Remote Logging" seems broken
Omada Controller "Remote Logging" seems broken
2022-02-23 23:07:47

Hello,

 

Omada Controller's "remote logging" seems broken.  It seems TP-Link doesn't follow the "obsoleted" bsd syslog protocol, not even the latest one published back in 2009.

 

RFC3164 - BSD Syslog Protocol (obsolete by RFC5424)

RFC5424 - Syslog Protocol (Obsoletes RFC3164)

 

We configured the Omada Controller to "remote log".  On the other end, we use a very popular agent named Telegraf.  It supports both the old and new syslog protocols.

 

In Telegraf, we tried both protocols and none worked.  In Telegraf, enabling the "best_effort" option didn't help either.

 

best_effort : instructs the parser to extract partial but valid info from syslog messages. If unset only full messages will be collected.

 

In the end messages can't be read by Telegraf.

 

Per the tests, it seems you guys have close to RFC3164.  The timestamp and severity level are there but the remaining of the information is either complitely missing and/or not properly aligned in the message created by the Omada software.


It's going to be a big blocker to move with TP-Link.  Data is crucial for security systems that injest the "network" information and based on the analysis of the data, it can take immediate action and prevent a hacker to achieve its goal.

 

@Fae low priority, could you check if the dev team could do a quick fix the logging?  If the current function to send a message is missing any field, a temporary fix is set it to a "-" (dash).  I estimate a senior dev person can do a fix in ~1h30-2h30 work, this would make the product compliant to at least 1 RFC.

 

We're using current latest Omada Controller v5.0.30 in a docker instance.

 

Thanx //

  0      
  0      
#1
Options
2 Reply
Re:Omada Controller "Remote Logging" seems broken
2022-02-24 06:47:25 - last edited 2022-02-24 06:47:43

Dear @EuphoricHacker,

 

EuphoricHacker wrote

could you check if the dev team could do a quick fix the logging?  If the current function to send a message is missing any field, a temporary fix is set it to a "-" (dash).  I estimate a senior dev person can do a fix in ~1h30-2h30 work, this would make the product compliant to at least 1 RFC.

 

Thank you for posting the problem o the TP-Link Community.

 

In fact, the syslog is sent by devices instead of by the Controller, Controller only manage the devices.

 

To address the issue, could you please provide the model number, hardware and firmware version of your Omada devices?

Would all of those devices have the same issue with the Telegraf?

>> Omada EAP Firmware Trial Available Here << *Try filtering posts on each forum by Label of [Early Access]*
  0  
  0  
#2
Options
Re:Omada Controller "Remote Logging" seems broken
2022-02-24 14:12:23 - last edited 2022-02-24 14:13:07

Fae wrote

Thank you for posting the problem o the TP-Link Community.

 

In fact, the syslog is sent by devices instead of by the Controller, Controller only manage the devices.

 

To address the issue, could you please provide the model number, hardware and firmware version of your Omada devices?

Would all of those devices have the same issue with the Telegraf?

 

@Fae I had not realized the logs come directly from each AP/switches.

 

Our lab are currently testing with 2 x EAP660HD both running "1.1.0 Build 20211223 Rel. 63013" (beta for mesh if I recall properly).

 

I can't answer if all devices have the same issue since our lab is 2 of the same model.  If the "latest" AP/switches use the same "code base" for the logging, then it's 1 change to do for all AP/switches.

 

I can understand why Tp-Link remote syslog doesn't follow RFCs, it was and is likely still today a low priority.  We're now in 2022, hackers are active like never.  Corporations (prosumers) around the world have started to install "AI security systems" products that take actions based on the collected logs.  Often the action to take is to block an IP/device to enter the network.

 

In our new lab, the only missing block that we have now is the logging from Tp-Link equipments.  If the equipment doesn't send "valuable informations", it's also possible the logging will be completely/partially useless.  We noticed Omada Controller has a lot of information for each connected devices, somone has to wonder .. why not add an option as well in the controller to send its logging to a remote server?

 

We also noticed Omada documentation http://omada-sdn.docs.tplinkusa.com/en/latest/onboarding/omada_api.html as a reference to this project https://github.com/ghaberek/omada-api -  the project isn't sponsored/maintained by TpLink but by a 3rd party.  It would require more work for us and since it's not a Tp-Link project, we don't want to go in that direction.

 

What we hope is your dev team to commit to make the required changes.  My 2 cents... since Omada Controller already gather tons of informations, it seems Tp-Link should focus to add a "remote logging" option directly within the controller.  Basically, the controller would have 2 "remote logging" options.

 

1) keep the current "device logging", e.g. each device sends its log to a remote server

2) Omada Controller new "remote logging", e.g. the controller sends its logs to a remote server (keep a local copy as well).  The end-user should also be able to control the minimum severity level (debug, info, error, etc).

 

We still have ~3-6 months ahead of us before we take the final decision.  Again, this is low priority.  Hoping you come back within next 2 weeks with some news from the dev team on how they plan to proceed in the near? future.

 

// Thank you.

  0  
  0  
#3
Options