[rsyslog] more 5.1.3 errors (fwd) / invalid fromhost

Rainer Gerhards rgerhards at hq.adiscon.com
Fri Aug 21 12:54:03 CEST 2009


> >> the second problem from my initial e-mail (and the one I mentioned
> in
> >> response to the 5.1.4 release) is pointed out by this portion of my
> >> initial e-mail
> >>
> >> <29>Jul 31 21:33:39 methane1d-b plug-gw[13212]: connect host=
> >> /192.168.243.38 destination=179.50.100.130/11074
> >>
> >> 192.168.210.245 192.168.210.245 methane1d-b
> >>
> >>
> >> in addition to not parsing the message correctly and putting the
> >> hostnmae
> >> in the syslogtag field, the fromhost is incorrect. this message
> could
> >> only
> >> have gotten here by being relayed from the .219 box. the log file on
> >> the
> >> .245 box (which logs *.* to messages) don't show anything like this,
> >> and
> >> the methane1d-b box doesn't have any networks in common with the
> .245
> >> box
> >
> > Is there any possibility that *any* message was previously received
> from
> > .245? From what you said, I assume not. I am asking because the
> problem may
> > be related to the name lookup reuse technique (which re-uses the
> sender IP if
> > it is the same as with the last UDP packet). However, the problem can
> only be
> > rooted in that area if .245 is a valid sender at least at times.
> 
> yes, .245 is a valid sender (in fact, in the main set of mssages I sent
> initilly all the messages from .245 are legit)
> 
> all of the sources listed in the config do send messages (for each
> pair,
> one is the active relay sending hundreds to thousands of messages/sec
> while the other is the backup, sending a handful per min)

OK, this looks like it narrows down the code to look at to a relatively small
portion. Will give that another review.

> > I have also done a source code review right now, but I do not see any
> > suspicious. Will continue to try a little bit, but that one does
> probably
> > need to wait until we can do some debugging in your environment.
> 
> understood. I may try to go in over the weekend and setup this sort of
> test.

Do you think this can be easily reproduced? If so, that would be great. I
could simply comment out some of the code I suspect to cause the bug and so
we could check both versions and see if it makes a difference...

Rainer



More information about the rsyslog mailing list