1.6.0rc1 / SunOS 5.8 (Solaris 8) - entries not logged with IP address
I am still trying to solve this problem. I have verirified from debugging that there is some disconnect in the values salen and addrlen and between A_RECV(read, closure->max_log_line - closure->pos, closure-> buffer + closure->pos, (abstract_addr *) &sabuf, &salen); in syslog-ng-1.6rc0/src/sources.c and res = recvfrom(closure->fd, buffer, length, 0, (struct sockaddr *) addr, (socklen_t *) addrlen); in libol-0.3.9/src/io.c. salen is set to 256 before and after the A_RECV() is called, but addrlen is set to 0 and sockaddr seems to point to nothing in before recvfrom() is called. As a result recvfrom() simply doesn't record the address information of the sending host. This is on SunOS-5.8-sparc in 64-bit mode with gcc 3.2.1 compiling 64-bit binaries. Anyway, the result is that syslog-ng is unable to record the address of the sending host and winds up prepending all logged messages with it's own hostname, rather than the sending host's. With all of the casting and and abstraction involved in the code, I am not sure what to try next. Any suggestions? Is this a 64-bit problem? Brian
On Wed, Apr 16, 2003 at 11:01:56PM -0700, Brian C. Hill wrote:
I am still trying to solve this problem.
I have verirified from debugging that there is some disconnect in the values salen and addrlen and between
A_RECV(read, closure->max_log_line - closure->pos, closure-> buffer + closure->pos, (abstract_addr *) &sabuf, &salen);
in syslog-ng-1.6rc0/src/sources.c and
res = recvfrom(closure->fd, buffer, length, 0, (struct sockaddr *) addr, (socklen_t *) addrlen);
in libol-0.3.9/src/io.c. salen is set to 256 before and after the A_RECV() is called, but addrlen is set to 0 and sockaddr seems to point to nothing in before recvfrom() is called. As a result recvfrom() simply doesn't record the address information of the sending host.
This is on SunOS-5.8-sparc in 64-bit mode with gcc 3.2.1 compiling 64-bit binaries.
Anyway, the result is that syslog-ng is unable to record the address of the sending host and winds up prepending all logged messages with it's own hostname, rather than the sending host's.
With all of the casting and and abstraction involved in the code, I am not sure what to try next.
Any suggestions? Is this a 64-bit problem?
syslog-ng has never been compiled in 64bit userspace, therefore it is almost certain that you will run into problems. IMHO you should try to compile syslog-ng as a 32 bit executable. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Hi Bazsi, Thanks for the quick reply. I did and that fixed the problem. Since that was the only problem I ran into in 64-bit mode, I would like to be able to compile it that way again for consistency with other applications. Do you have a quick thought as to which data structures might be affected by te 64-bit compile that are related to the recvfrom part of the code? Brian ====================================================================== On Fri, Apr 18, 2003 at 10:44:24AM +0200, Balazs Scheidler wrote:
On Wed, Apr 16, 2003 at 11:01:56PM -0700, Brian C. Hill wrote:
I am still trying to solve this problem.
I have verirified from debugging that there is some disconnect in the values salen and addrlen and between
A_RECV(read, closure->max_log_line - closure->pos, closure-> buffer + closure->pos, (abstract_addr *) &sabuf, &salen);
in syslog-ng-1.6rc0/src/sources.c and
res = recvfrom(closure->fd, buffer, length, 0, (struct sockaddr *) addr, (socklen_t *) addrlen);
in libol-0.3.9/src/io.c. salen is set to 256 before and after the A_RECV() is called, but addrlen is set to 0 and sockaddr seems to point to nothing in before recvfrom() is called. As a result recvfrom() simply doesn't record the address information of the sending host.
This is on SunOS-5.8-sparc in 64-bit mode with gcc 3.2.1 compiling 64-bit binaries.
Anyway, the result is that syslog-ng is unable to record the address of the sending host and winds up prepending all logged messages with it's own hostname, rather than the sending host's.
With all of the casting and and abstraction involved in the code, I am not sure what to try next.
Any suggestions? Is this a 64-bit problem?
syslog-ng has never been compiled in 64bit userspace, therefore it is almost certain that you will run into problems.
IMHO you should try to compile syslog-ng as a 32 bit executable.
-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- _____________________________________________________________________ / Brian C. Hill bchill@bch.net http://brian.bch.net \ | Unix Specialist BCH Technical Services http://www.bch.net |
On Fri, Apr 18, 2003 at 02:10:33AM -0700, Brian C. Hill wrote:
Hi Bazsi,
Thanks for the quick reply.
I did and that fixed the problem. Since that was the only problem I ran into in 64-bit mode, I would like to be able to compile it that way again for consistency with other applications.
Do you have a quick thought as to which data structures might be affected by te 64-bit compile that are related to the recvfrom part of the code?
you might try this patch: Index: abstract_io.h =================================================================== RCS file: /var/cvs/syslog-ng/libol/src/abstract_io.h,v retrieving revision 1.6 diff -u -r1.6 abstract_io.h --- abstract_io.h 15 Mar 2000 16:41:52 -0000 1.6 +++ abstract_io.h 18 Apr 2003 10:57:38 -0000 @@ -48,7 +48,7 @@ (name abstract_read) (vars (read indirect-method int "UINT32 length" "UINT8 *buffer") - (recv indirect-method int "UINT32 length" "UINT8 *buffer" "abstract_addr *addr" "int *addrsize"))) + (recv indirect-method int "UINT32 length" "UINT8 *buffer" "abstract_addr *addr" "size_t *addrsize"))) */ #define A_READ(f, length, buffer) (f)->read(&(f), (length), (buffer)) Index: io.c =================================================================== RCS file: /var/cvs/syslog-ng/libol/src/io.c,v retrieving revision 1.35 diff -u -r1.35 io.c --- io.c 31 Jan 2003 09:27:02 -0000 1.35 +++ io.c 18 Apr 2003 10:57:38 -0000 @@ -361,7 +361,7 @@ } } -static int do_recv(struct abstract_read **r, UINT32 length, UINT8 *buffer, abstract_addr *addr, int *addrlen) +static int do_recv(struct abstract_read **r, UINT32 length, UINT8 *buffer, abstract_addr *addr, socklen_t *addrlen) { CAST(fd_read, closure, *r); -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Hi Bazsi, I don't have scheme shell. Can you apply this to a snapshot? Brian ====================================================================== On Fri, Apr 18, 2003 at 12:58:59PM +0200, Balazs Scheidler wrote:
On Fri, Apr 18, 2003 at 02:10:33AM -0700, Brian C. Hill wrote:
Hi Bazsi,
Thanks for the quick reply.
I did and that fixed the problem. Since that was the only problem I ran into in 64-bit mode, I would like to be able to compile it that way again for consistency with other applications.
Do you have a quick thought as to which data structures might be affected by te 64-bit compile that are related to the recvfrom part of the code?
you might try this patch:
Index: abstract_io.h =================================================================== RCS file: /var/cvs/syslog-ng/libol/src/abstract_io.h,v retrieving revision 1.6 diff -u -r1.6 abstract_io.h --- abstract_io.h 15 Mar 2000 16:41:52 -0000 1.6 +++ abstract_io.h 18 Apr 2003 10:57:38 -0000 @@ -48,7 +48,7 @@ (name abstract_read) (vars (read indirect-method int "UINT32 length" "UINT8 *buffer") - (recv indirect-method int "UINT32 length" "UINT8 *buffer" "abstract_addr *addr" "int *addrsize"))) + (recv indirect-method int "UINT32 length" "UINT8 *buffer" "abstract_addr *addr" "size_t *addrsize"))) */
#define A_READ(f, length, buffer) (f)->read(&(f), (length), (buffer)) Index: io.c =================================================================== RCS file: /var/cvs/syslog-ng/libol/src/io.c,v retrieving revision 1.35 diff -u -r1.35 io.c --- io.c 31 Jan 2003 09:27:02 -0000 1.35 +++ io.c 18 Apr 2003 10:57:38 -0000 @@ -361,7 +361,7 @@ } }
-static int do_recv(struct abstract_read **r, UINT32 length, UINT8 *buffer, abstract_addr *addr, int *addrlen) +static int do_recv(struct abstract_read **r, UINT32 length, UINT8 *buffer, abstract_addr *addr, socklen_t *addrlen) { CAST(fd_read, closure, *r);
-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- _____________________________________________________________________ / Brian C. Hill bchill@bch.net http://brian.bch.net \ | Unix Specialist BCH Technical Services http://www.bch.net |
On Wed, Apr 30, 2003 at 12:25:48PM -0700, Brian C. Hill wrote:
Hi Bazsi,
I don't have scheme shell. Can you apply this to a snapshot?
snapshots are generated automatically based on my CVS tree each morning at around 6am CET (GMT +0100) So it will be available at tomorrow morning snpshot. The change I made was a libol change, so you need the libol snapshot. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Okay. Thanks. Brian ====================================================================== On Wed, Apr 30, 2003 at 11:58:51PM +0200, Balazs Scheidler wrote:
On Wed, Apr 30, 2003 at 12:25:48PM -0700, Brian C. Hill wrote:
Hi Bazsi,
I don't have scheme shell. Can you apply this to a snapshot?
snapshots are generated automatically based on my CVS tree each morning at around 6am CET (GMT +0100)
So it will be available at tomorrow morning snpshot. The change I made was a libol change, so you need the libol snapshot.
-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- _____________________________________________________________________ / Brian C. Hill bchill@bch.net http://brian.bch.net \ | Unix Specialist BCH Technical Services http://www.bch.net |
participants (2)
-
Balazs Scheidler
-
Brian C. Hill