This is not a question, just informational.

Logging and documentation are not TP-Links' strengths, and the logging options can be hard to find for your specific device model. Their document "Configuring System Logs" is limited to a specific series of switches, and the information is not compatible with Omada and the devices I own. I am sharing what I rediscovered this morning, hoping this will help others or myself when I need to modify the settings again. I am currently investigating the significant rise with inbound threats to my network.

Enable SYSLOG - (Omada Cloud Controller)

To enable SYSLOG, the settings are found on the Omada Cloud Controller by clicking the gear icon in the lower left of the page. It is then found under Site/Services. This is where you enable Remote Logging, identify the Syslog Server by hostname or IP, SYSLOG Server Port, and enable "Client Log Details". The default SYSLOG port is 514/UDP, and there is no option to use TCP.   I cannot find any document, or click through the menus to find custom logging levels.

Customizable Logging Features - (Local Omada Controller)

On the local controller, you can enable SYSLOG under Controller Settings / Services, and customize logging levells under System Settings and System Logging. There are seven customisable logging options: Logging Level Type, Manager Logs, Client Info Logs, Network Monitoring Logs, System Setting Logs, Account Logs, Log-related Operation Logs, and Others. It seems that the "Client Log Details" checkbox on the Omada Cloud Controller is the same as "Client Info Logs" on the local controller.

 Omada supports three levels for each logging option: Warn, Info, and Debug.


Problems:

1: I can sort of understand why logging options are different between Omada cloud and the local Omada controller, but I have yet to find official TP-Link documentation that explains this.

2: TP-Link does not provide a mechanism to send a test SYSLOG message for troubleshooting. I use Kiwi SYSLOG Message Generator because it is a free tool for Windows, helpful for testing a new SYSLOG server installation.  But it doesn't troubleshoot from the OC200/OC300 perspective.

3: I am finding a significant latency between the logged event in Omada and when SYSLOG timestamps the received message.  The latency is typically around 55 seconds but can be longer. The latency between Kiwi on my laptop and the SYSLOG server is typically less than a second. My router is currently dropping attack-related packets, and I have spanned a port to a Linux laptop for continuous packet capture. These two activities are going to impact the router's performance. As for my network configuration, all devices use the same NTP sources, and all devices are on the same subnet. The OC200 and my Windows laptop are connected to the same SG2008P switch which is connected to the ER605 router. The SYSLOG server is connected to the ER605 router. To confirm the system time on the Omada controller, you must log in locally, and click the Gear icon at the bottom left of the local Omada webpage. The System Time continuously updates.

3a: Example: On Nov 12, tshark captured the following packet at 20:08:04 that contained a TCP noFlag packet, and it roughly corresponds to the only packet dropped at the router at 20:11:43. The SYSLOG server received and timestamped the event at 20:12:38, and only one noFlag packet was reported that hour..

[bob@linux] tshark -t ad -r  WAN_00002_20231112200502.pcap -Y "(tcp.flags == 0x000)"
2023-11-12 20:08:04.448169391 xxx.xxx.xxx.xxx → xxx.xxx.xxx.xxx TCP 74 [TCP ZeroWindow] 35170 → 34221 [<None>] Seq=1 Win=0 Len=0 MSS=1412 SACK_PERM TSval=3312398226 TSecr=0 WS=64

I eyeballed the system time on the Omada Controller and SYSLOG server, and they are in sync. I am using tshark on the SYSLOG server and this is the timestamp of the event in the pcap file.

Latency:
packet captured in tshark - 20:08:04
Omada drops packet        - 20:11:43 (latency: 3 minutes, 39 seconds from capture)

Nov 12 20:12:38 192.168.0.2  2023-11-12 20:11:43 OC200 - - - [osg:ER605:10-27-F5-xxx-xx-xx] detected TCP no-Flag attack and dropped 1 packets.#015

Syslog Received               - 20:12:38 (latency: 4 minutes, 34 seconds from capture)

4: Debug level is not verbose enough when trying to associate dropped packets related to an attack. The debug SYSLOG message fails to identify the following details:  source and destination address, router port number, and whether the packet was ingress or egress. I cannot find a Wireshark Display Filter that matches dropped packets due to SYN-and-FIN attacks.  I can easily find the packet dropped with no-Flag.