MonitorWare Knowledge Base

I'm trying to pin down if I'm misunderstanding the docs or if there's something going wrong here. With this config file:

$ModLoad imudp.so
$UDPServerAddress 216.143.nnn.nnn
$UDPServerRun 514

#$template as5400Format,"%syslogtag%%msg%\n"
#$template as5400Format,"%syslogtag%%msg:::drop-last-lf%\n"
$template as5400Format,"%syslogtag%%msg:::space-cc%\n"


:HOSTNAME,startswith,"peabody" /var/log/as5400/jfk/jfk.log;as5400Format
:HOSTNAME,startswith,"peabody" ~

*.* /var/log/as5400/test.log

I would expect that everything coming from a host with a name starting "peabody" would end up in jfk.log, that those messages would then be discarded, leaving everything else to end up in test.log.

I would further expect that in jfk.log, control characters would be converted into spaces and in test.log they would be passed through as-is.

Instead what I get is that

jfk.log:

650486165 Feb 12 03:25:36.323: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
650486166 Received:
650486167 OPTIONS sip:lata224gw.vantageip.net:5060 SIP/2.0#015
650486168 Via: SIP/2.0/UDP 216.143.148.116:5060;branch=z9hG4bKvbono6309811obojl241#015

looks like escape-cc is specified, and

test.log:

Feb 12 03:24:40 phlsniff rsyslogd: [origin software="rsyslogd" swVersion="3.11.0" x-pid="26893"] restart
Feb 12 03:25:36 peabodybge0.bw.dca.vantageip.net 650486165 Feb 12 03:25:36.323: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMs
g:
Feb 12 03:25:36 peabodybge0.bw.dca.vantageip.net 650486166 Received:
Feb 12 03:25:36 peabodybge0.bw.dca.vantageip.net 650486167 OPTIONS sip:lata224gw.vantageip.net:5060 SIP/2.0#015
Feb 12 03:25:36 peabodybge0.bw.dca.vantageip.net 650486168 Via: SIP/2.0/UDP 216.143.148.116:5060;branch=z9hG4bKvbono6309
811obojl241#015

has the local log lines as well as all the peabody stuff, and also looks like it's using escape-cc.

BTW, things look the same no matter which of those 3 template lines I have uncommented.

I am going to set things up to sniff the packets on the wire to see if all those "#015" bits are in the UDP packets as literals, but they don't show up in the local log files on peabody, which is receiving them from a 3rd device and both logging them locally and forwarding them to the server running rsyslog, so I suspect they're in the packets as control characters.

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

I guess the #015's are rsyslog escaped. The config looks good. I'll check what's going on...

Rainer

oh, one thing - could you run rsyslog interactively in debug mode (-d -n) and provide me some of the output. I guess that would be very helpful.

Thanks,
Rainer

Well, I think I now at least know why the discard doesn't work - its related to a bug that I already posted:

http://sourceforge.net/tracker/index.ph ... tid=696552

lol... on the space-cc: we built ourselves a trap.

This is needed in rsyslog.conf:
$EscapeControlCharactersOnReceive off

This setting by default is on (part of sysklogd compatibility). If it is on, it escapes the characters directly when the message is received and so there is nothing left for escape-cc. I will make sure the doc properly reflects this. Next thing to fix is the discard problem.

Rainer

Its fixed now in cvs. I hope I manage to do a new release today, else tomorrow. If I don't manage today, I can provide a preview tarball if its urgent for you.

Rainer

All of which means, I assume, you don't need a debug on this stuff....

I can confirm that

$EscapeControlCharactersOnReceive off

makes things work just fine with the control character settings. I'll standby for the actual release if it's in the next day or so. But...see my next topic for another issue I'm having with 3.11.00, complete with traceback information.

Thanks.

Jon,

great, and, of course, no debug required. I am quite happy to receive this reports - as I initially wrote, 3.11.0 has lots of new code and it needs practical experience to get it rock-solid Looking forward to the next one.

We have also just now set up a new feature tracker at http://www.rsyslog.com/bugs - as you are probably quite sure it is a bug, you can also post there. Just a suggestion. Either way is fine

Rainer

Well... I've just put together a quick preview at http://download.rsyslog.com/rsyslog/rsy ... pre.tar.gz

I have not run it through the release tests and I have not tried to compile as release build. But chances are great it will work for you (and doesn't need modification for final release unless whatever you report next can be so quickly fixed that it will become part of that release).

Feedback is appreciated.

Rainer

EDIT: corrected wrong download link