MonitorWare Knowledge Base

Hi, I have tried rsyslog today. It is working great while log the Linux machines. But I am facing a serious problems while it log the Netscreen firewall log. It was installed in a Debian Etch.

The log of the netscreen in the /var/log/syslog was not in well format. It cannot know the delimit each record from netscreen.

I would like to know which article can teach me how to set the delimiter. It will be good if there is a example too.

Thank you very much.

• Pulling out your Hair?
• Wasting Time and Money?
• Deadline Approaching?

Do you have an example of the netscreen format you receive? I need both the raw format as well as what rsyslog parses out of it

Rainer

Thanks for reply.

Actually, problem can be fixed when I set the netscreen from using tcp to udp to export the log.

The previous log is that each record is combined together with a tag. Rsyslog is split it every 2047 char.

That sounds like a bug in Netscreen. They seem not to use the usual terminator (LF). Anyhow, I am glad you found a solution.

Rainer

Hi,

I've got the same problem with the netscreens, rsyslog and the tcp protocol.
Netscreen doesn't use the LF as a line terminator. The messages are separated by a null char.
Switching to UDP is not an option. Any ideas ?

Arv.

arv wrote:Hi,

I've got the same problem with the netscreens, rsyslog and the tcp protocol.
Netscreen doesn't use the LF as a line terminator. The messages are separated by a null char.
Switching to UDP is not an option. Any ideas ?

Arv.

brrr... any chance you can at least file a bug report with them? This is really horrible... I'll see what I can do, but again, someone should slap them

Is it really a bug in netscreen?
The RFC3164 doesn't seem to mention line breaks.
Netscreen works perfectly over tcp with syslog-ng and kiwi's syslog as well.

Arv.

Well, one may argue if it is a bug or not, because there is no defintive reference. RFC 3164 is it not, for various reasons with the most important being that it doesn't talk at all about plain tcp syslog. The industry-standard is that LF is used as framing. Kiwi, I think, has a broken handling of TCP segments and I don't know why syslog-ng works. Maybe it has the same problem, maybe it accepts NUL characters as terminators, too. At least in the Kiwi case when two broken implementations look like a fix (and work under usual conditions, but only them...) that doesn't make a sound technical solution .

Quite honestly, I think you can be happy that there is the NUL character. Usually, it happens to be there because the developer did not properly parse the length parameter when issuing the send() call, a common programming error, but, hey, we are so thankful for every broken program that by virtue of doing things wrong help us to escape wrongness a bit. I know this all sounds pretty ignorant, but I have seen so many borken implementations in the past 10+ years ... and I have mode so many programming errors myself that I really know what I am talking about.

I would be most interested to hear what the Netscreen folks say. Of course I can (and probably will) add a work-around for another far-from-what-is-standard implementation, but I think those vendors need at least to know what they are doing...

Rainer

I will open a case in the Juniper's support (why not). I was just looking for an arguments for them. That's why I've read those RFC's .
Switching to syslog-ng for me is not an option too. The reasons are well described here:
http://blog.gerhards.net/2007/08/why-does-world-need-another-syslogd.html


Arv.

Thanks for quoting me As I said, I'll add a work-around as soon as I can. Thanks to the NUL (which I bet is not deliberately introduced ) this is possible without much effort. But it becomes a problem if you have multiple devices, some behaving correctly, some not. So question now: do you have other devices (different vendors etc) also reporting to the same instance.

Also note that sometimes vendors do internal code audits. More than once, these spurios NULs then disappear (as I said, they are usually the result of a coding error). So it is a bit dangerous to rely on them. Hopefully the support case will tell Juniper that these should be preserved. And, yes, I have seen those NULs go away on different occasions.

You may also want to have a look at this thread here for more arguments:

tcp-syslog-fill-s-up-buffer-and-doesn-t-log-single-events-t8705.html

Rainer

Thanks a lot for Your time .
I have a few devices from few vendors, and I wish I could collect all logs from them.

Arv,

If you can get 'em into line format, I think we can figure out how to dissect 'em into fields!

Check out: cisco-pix-asa-logging-starter-t8720.html

There's a good starter for Cisco's ASA/PIX. Good stuff (If is say so myself )
With that you should be able to get a start on parsing lines into fields.
Once you get the hang of it it's not too bad.
Hey, sliced bread doesn't think it's so good when you show it a copy of rsyslog!

arv wrote:Thanks a lot for Your time .
I have a few devices from few vendors, and I wish I could collect all logs from them.

This is where the trouble starts. Those other devices probably behave correctly. So if you set the frame delimiter to NUL, that will cause problems to them...

arv wrote:Hi,

I've got the same problem with the netscreens, rsyslog and the tcp protocol.
Netscreen doesn't use the LF as a line terminator. The messages are separated by a null char.
Switching to UDP is not an option. Any ideas ?

Arv.

Would it be possible just to handle things just like that ?

Code: Select all

# diff tcps_sess.c tcps_sess_try.c
316c316
<               if(c == '\n' && pThis->eFraming == TCP_FRAMING_OCTET_STUFFING) { /* record delemiter? */
---
>               if( (c == '\n' || c == '\0') && pThis->eFraming == TCP_FRAMING_OCTET_STUFFING) { /* record delemiter? */


It doesn't look like a 1000e worth patch .

Arv.

Well, I doubt it works, but why not give it a try? Please report the results back. In any case, that is not a really clean solution. I think this thread has a lot of information why it is not.