08-13-2011, 08:21 AM (This post was last modified: 08-26-2014, 05:31 PM by wuench.)
Syslog Driver Version 1.1
Description:
This driver allows you to send and receive Syslog messages. The driver can also act as a Syslog relay to relay any messages recieved to another Syslog server. When a new message is received a User Action Event will also be generated which can be used in Triggered Events to cause other things to happen in CQC.
Usage Examples/Ideas
Log info to an external Syslog server based on CQC Events
Trigger a CQC event based on Syslog event - Have CQC speak whenever someone new connects to your access point and email their MAC address
Have CQC email whenever your router drops it's WAN connection
Release Info
[indent]Version 1.0 - Original Version Version 1.1 - Header fix, Clean Message (Thanks Whozeawhat)[/indent]
Troubleshooting:
If possible please post a debug log of your issue if you are experiencing problems. To create a debug log, set the DebugMode field to True while the problem is occurring. This will create a log file on the machine running the driver under Program Files\CQC\CQCData\MacroFileRoot\Logs. Then zip the file and post it with your problem.
08-13-2011, 12:43 PM (This post was last modified: 08-13-2011, 12:46 PM by wuench.)
The following example looks for a DHCP query on my access point and logs the message which includes the MAC address. It then announces the event via the ELK M1.
The event uses Is User Action For, with a Comp Value of Syslog (my drivers moniker).
It gets the Event info into two local variables, then parses out the Host and Message text from the comma delimited list. It checks the message text to see if it is a DHCP message (DPT=67) and that it came in on my Guest access point interface (ACCEPT IN=br1) and that the timer isn't set. Then it sets a timer in a timer driver to prevent the event being triggered again for 1 min (since DHCP messages usually come in batches), logs the message and makes the announcement.
Code:
TrigEvent::GetUserActionVals(LVar:Type, LVar:Value)
System::GetNthToken(%(LVar:Value), ,, 1, LVar:Host)
System::GetNthToken(%(LVar:Value), ,, 4, LVar:Msg)
If System::Equals($(Timers.CDTimer4), 0)
If System::Equals(%(LVar:Host), ap.marionscove)
If LocalVars::Find(LVar:Msg, LVar:FoundAt, ACCEPT IN=br1, False)
If LocalVars::Find(LVar:Msg, LVar:FoundAt, DPT=67, False)
System::LogMsg(Logger, 0, New Guest Network DHCP Request, Status)
System::LogMsg(Logger, 0, %(LVar:Msg), Status)
Devices::FieldWrite(Security.SayPhrase, 248, True)
Devices::FieldWrite(Timers.InvokeCmd, ResetCD 4 Minutes 1, True)
End
End
End
End
Well, after troubleshooting my router's syslog message format, in conjunction with the Generic Syslog driver (version 1.0), I've adjusted the code behind processing each syslog message. This should hopefully be no impact to all other users and allow for older (or slightly-alternative) syslog messages (such as the message format from Netgear's FVS318v3 router).
I hope this will eventually make it into the standard CQC release, with the permission/review of the driver's author, of course. If not, this post will at least allow other users to potentially be aware of possible issues.
In my case, there were 2 issues, both causing Exception/warning errors in the CQC log. First, the syslog message itself contained a comma, which did not allow for the correct indexing later. Additionally, the message text contained a newline/feed form. Both of these issues are resolved by the following code additions.
Added to method: GetMsg() [first and last line already contained in version 1.0 of driver, provided for reference/position]
strDate.AppendFmt(timeStamp);
//[BEGIN new code]
// Add syslog message pre-header, if required
If (!strResp.StartsWith("<",False))
strResp.StripChars("[<>]");
// next line adds a standard location/severity to all messages
strResp.Prepend("<134> ");
EndIf;
// Clean message
strResp.ReplaceChar('\n',' ');
strResp.ReplaceChar('\f',' ');
strResp.ReplaceChar('\t',' ');
strResp.ReplaceChar('\r',' ');
strResp.ReplaceChar(',','-');
//[END new code]
// Get Source IP
Thanks to all to contribute and support, especially Dean and wuench
Thanks, i'll take a look at it once I get done with the XBMC stuff. Unfortunately Syslog is a very loose protocol, and I have seen some crazy stuff get sent from devices, so keeping the parsing minimal is the only way to maintain support. I guess my parsing wasn't minimal enough..
Not sure if you plan on updating this driver, but it doesn't send syslog messages because it doesn't support the new socket binding. Maybe other issues, but that's what I found.