> the string <190> is the encoded priority and severity of the message (in this > case local7.user). A properly formatted syslog message will have this (try > sending a message with the format RSYSLOG_Traditional_Forward_Format and you > should see a similar thing before the timestamp) If this is breaking the > message parsing, the receiving system is broken
I think you mean local7.info? ;-) Thanks for the explanation. Anyway, if I just send a message directly to it the system works fine so this isn't apparently a problem. It's just having issues with the udpspoofed messages. >> Here's some examples -- msg:2:2048 created with logger -p local7.info "123 >> This is another test message" and forwarded via udpspoof >> >> 0000 78 2b cb 29 ff 1b 00 26 b9 33 00 3a 08 00 4a 00 x+.)...& .3.:..J. >> 0010 00 52 00 f2 00 00 40 11 b6 bd 0a d2 82 76 0a d2 .R....@. .....v.. >> 0020 1e ca 00 01 01 01 01 01 01 01 01 01 01 00 01 01 ........ ........ >> 0030 00 01 00 01 01 00 07 7d 05 ea 00 2a 63 a3 31 32 .......} ...*c.12 >> 0040 33 20 54 68 69 73 20 69 73 20 61 6e 6f 74 68 65 3 This i s anothe >> 0050 72 20 74 65 73 74 20 6d 65 73 73 61 67 65 2e 0a r test m essage.. >> >> rawmsg created with logger -p local7.info 123 "This is another test message" >> and forwarded via udpspoof >> >> 0000 78 2b cb 29 ff 1b 00 26 b9 33 00 3a 08 00 4a 00 x+.)...& .3.:..J. >> 0010 00 79 00 f2 00 00 40 11 b6 9a 0a d2 82 76 0a d2 .y....@. .....v.. >> 0020 1e ca 01 00 01 01 00 00 00 01 01 01 01 00 00 00 ........ ........ >> 0030 01 01 01 00 01 00 02 7d 05 ea 00 51 33 98 3c 31 .......} ...Q3.<1 >> 0040 39 30 3e 41 70 72 20 32 30 20 31 31 3a 30 30 3a 90>Apr 2 0 11:00: >> 0050 30 36 20 73 32 32 2d 77 77 77 30 38 20 6a 6f 72 06 s22-w ww08 jor >> >> Here's a normal syslog message from the same host sent directly, not >> forwarded by udpspoof: you might recognize the message ;-) >> >> 0000 78 2b cb 29 ff 1b 00 26 b9 33 00 3a 08 00 45 00 x+.)...& .3.:..E. >> 0010 00 6d 00 00 40 00 40 11 e7 53 0a d2 1e bf 0a d2 .m..@.@. .S...... >> 0020 1e ca cb aa 05 ea 00 59 32 64 41 70 72 20 32 30 .......Y 2dApr 20 >> 0030 20 31 37 3a 35 39 3a 33 37 20 73 32 32 2d 66 32 17:59:3 7 s22-f2 >> 0040 30 31 20 6b 65 72 6e 65 6c 3a 20 69 6d 6b 6c 6f 01 kerne l: imklo >> 0050 67 20 35 2e 38 2e 31 30 2c 20 6c 6f 67 20 73 6f g 5.8.10 , log so > > looking at these dumps, I don't think the problem is the <190>, I think the > problem is the three characters before that (Q3. in the text represnetation), > those start at the same point that the timestamp starts in the last example. Actually the timestamp starts like 18 bytes earlier in the normal non-spoofed example. Similar position in the row, but a whole row earlier. > note that the last example is missing the priority/severity information. This > is unfortunantly not an uncommon bug. That is straight from the following line in rsyslog.conf, so if that is broken then it's an rsyslog bug: kern.info @[zenhost]:1154 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards
