Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graylog incorrectly processes Syslog messages with incorrect version #3502

Closed
joschi opened this issue Feb 15, 2017 · 0 comments
Closed

Graylog incorrectly processes Syslog messages with incorrect version #3502

joschi opened this issue Feb 15, 2017 · 0 comments
Assignees
Labels
bug
Milestone

Comments

@joschi
Copy link
Contributor

@joschi joschi commented Feb 15, 2017

Since the changes for #2954, Graylog doesn't process syslog messages with an incorrect version (i. e. not 1) anymore.

Expected Behavior

The example message should be parsed correctly:

<12>0 2017-02-15T16:01:07.614260+01:00 vmlsfw test - - -  test 4

Current Behavior

The example message is parsed incorrectly:

<12>0 2017-02-15T16:01:07.614260+01:00 vmlsfw test - - -  test 4

From a unit test to reproduce the behavior:

0 = {HashMap$Node@3116} "level" -> "4"
1 = {HashMap$Node@3117} "_id" -> "98e03610-f39b-11e6-827e-6a9c47cfab13"
2 = {HashMap$Node@3118} "source" -> "2017-02-15T16:01:07.614260+01:00"
3 = {HashMap$Node@3119} "message" -> "2017-02-15T16:01:07.614260+01:00 vmlsfw test - - -  test 4"
4 = {HashMap$Node@3120} "facility" -> "user-level"
5 = {HashMap$Node@3121} "timestamp" -> "0000-01-01T00:00:00.000+00:53:28"

Possible Solution

Make parsing the syslog version more lenient (e. g. use [0-9] instead of [1-9]).

Also, using the predefined RSYSLOG_SyslogProtocol23Format template should work: https://github.com/rsyslog/rsyslog/blob/v7.6.7/runtime/rsconf.c#L87

Context

https://github.com/rsyslog/rsyslog/blob/v8.24.0/runtime/msg.h#L148-L150

Your Environment

  • Graylog Version: 2.2.0
  • rsyslog 7.6.7
@joschi joschi added the bug label Feb 15, 2017
@joschi joschi added this to the 2.2.1 milestone Feb 15, 2017
@joschi joschi self-assigned this Feb 15, 2017
joschi pushed a commit that referenced this issue Feb 15, 2017
Jochen Schalanda
Althought RFC 5424 clearly states that '1' is the only valid version for structured syslog
messages, some syslog daemons are using '0' as a version identifier.

https://tools.ietf.org/html/rfc5424#section-9.1

Fixes #3502
@joschi joschi added the in progress label Feb 15, 2017
@ghost ghost assigned dennisoelkers Feb 16, 2017
@ghost ghost removed the in progress label Feb 16, 2017
dennisoelkers added a commit that referenced this issue Feb 16, 2017
Althought RFC 5424 clearly states that '1' is the only valid version for structured syslog
messages, some syslog daemons are using '0' as a version identifier.

https://tools.ietf.org/html/rfc5424#section-9.1

Fixes #3502
dennisoelkers added a commit that referenced this issue Feb 16, 2017
Althought RFC 5424 clearly states that '1' is the only valid version for structured syslog
messages, some syslog daemons are using '0' as a version identifier.

https://tools.ietf.org/html/rfc5424#section-9.1

Fixes #3502
(cherry picked from commit af1a258)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants