Configuring syslog-ng to broadcast
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet. Previously the configuration line we used for a specific remote syslog was: destination grouplog { udp(192.168.1.14 port(514)); }; Can syslog-ng actually do udp broadcast, and if so, what would be the appropriate config line to cause this to happen? (I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.) [Jim Sky]
On 4/21/06, Jim Schuyler <sky@red7.com> wrote:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
IMHO, it's not always a _bad_ idea, if you really know why you're doing it.
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
What's the netmask of the interface on the host receiving these logs? Does 'netstat -nap udp' on the recieving host show *.514 as the listener? Is the sender on the same subnet as the receiving host? If not, does the router serving the receiver have "no ip directed-broadcast" or the equivalent setting? Kevin
Thanks so much for your reply. 1. The network is 192.168.1.* class C 2. The receiver's mask is 255.255.255.0 and he is at 192.168.1.14 3. The sender's mask is 255.255.255.0 and he is at 192.168.1.10 4. The router is not filtering within the network - only outside routes are filtered - and although I don't know about no ip directed-broadcast, snort and ipfw on the receiver tell me that there are broadcasts arriving at the receiver all the time (DHCP, for instance) 5. Syslog-ng successfully sends logs to 192.168.1.14 if I configure it using that specific IP address, so messages are getting thru 6. netstat on the receiver shows udp4 0 0 *.514 *.* udp46 0 0 *.514 *.* [I don't know why there are two entries - but it works] the receiver is a Mac OSX machine and one enables syslogd this way ("-u" means listen on udp port 514): sudo syslogd -m 0 -u Further help would be highly appreciated. My ultimate question is what the configuration line in syslog-ng should look like to get it to broadcast. Maybe this gives you enough information that we could figure that out. *If* syslog-ng can do broadcast, that is. [Jim] On 4/22/06 12:23 AM, "Kevin" <kkadow@gmail.com> wrote:
On 4/21/06, Jim Schuyler <sky@red7.com> wrote:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
IMHO, it's not always a _bad_ idea, if you really know why you're doing it.
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
What's the netmask of the interface on the host receiving these logs?
Does 'netstat -nap udp' on the recieving host show *.514 as the listener?
Is the sender on the same subnet as the receiving host? If not, does the router serving the receiver have "no ip directed-broadcast" or the equivalent setting?
Kevin _______________________________________________ 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
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262 Have a FIT! ... http://red7.com/fits.html
Hi, Jim Schuyler <sky@red7.com> [20060421 18:38:31 -0700]:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
Previously the configuration line we used for a specific remote syslog was:
destination grouplog { udp(192.168.1.14 port(514)); };
Can syslog-ng actually do udp broadcast, and if so, what would be the appropriate config line to cause this to happen?
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
If you look over the previous month or so worth of archive for this mailing list you will come across my multicast support patches. To send stuff to a multicast address you don't need to do anything special, but to receive it syslog-ng needs a light bit of patching. For the sort of thing you are after, it really sounds like multicasting would suit you far better. Cheers Alex
[Jim Sky]
_______________________________________________ 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
We are rewriting an existing bit of software and porting to Debian Linux. The old piece could use a UDP broadcast to send its logs, as well as specifying an IP address or a resolvable name. And they wrote custom code to do everything. Our approach is to use Debian packages for most things so we don't have to go write custom code. Vastly superior, but it means some of the things that were totally "exposed" before are now hidden. The problem is that our client requires that we exactly duplicate the previous capabilities - in this case that includes the broadcast. Also we do not have control over the "receiving" end. We cannot demand that it be syslog-ng. Any old syslog has to work. I wish it were so. Thank you for your suggestions. [Jim] On 4/22/06 9:28 AM, "Alexander Clouter" <ac56@soas.ac.uk> wrote:
Hi,
Jim Schuyler <sky@red7.com> [20060421 18:38:31 -0700]:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
Previously the configuration line we used for a specific remote syslog was:
destination grouplog { udp(192.168.1.14 port(514)); };
Can syslog-ng actually do udp broadcast, and if so, what would be the appropriate config line to cause this to happen?
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
If you look over the previous month or so worth of archive for this mailing list you will come across my multicast support patches. To send stuff to a multicast address you don't need to do anything special, but to receive it syslog-ng needs a light bit of patching.
For the sort of thing you are after, it really sounds like multicasting would suit you far better.
Cheers
Alex
[Jim Sky]
_______________________________________________ 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
_______________________________________________ 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
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262 Have a FIT! ... http://red7.com/fits.html
Hi, Ahhh, legacy 'fun' :) Jim Schuyler <sky@red7.com> [20060422 17:32:06 -0700]:
We are rewriting an existing bit of software and porting to Debian Linux. The old piece could use a UDP broadcast to send its logs, as well as specifying an IP address or a resolvable name. And they wrote custom code to do everything. Our approach is to use Debian packages for most things so we don't have to go write custom code. Vastly superior, but it means some of the things that were totally "exposed" before are now hidden. The problem is that our client requires that we exactly duplicate the previous capabilities - in this case that includes the broadcast.
If thats the case I would suggest you write a custom standalone reflector which takes regular unicast UDP packets, rewrites the destination and spits the packet back onto the wire. This could be done with twenty lines of Perl script or C code. syslog-ng would not have to be changed and you could use anything. The reflector would sit on the legacy subnet, everything outside that system would be able to continue as it was before.
Also we do not have control over the "receiving" end. We cannot demand that it be syslog-ng. Any old syslog has to work.
In my experienceits best trying to write 'translators' to get legacy stuff to behave better rather than bogging down 'new' code to speak to the legacy stuff. The idea is that then you only write the translator one rather than 'n' times for each bit of 'new' software you want to speak to the legacy system.
I wish it were so. Thank you for your suggestions.
If you still plan on re-writing a chunk of syslog-ng then I still suggest you look at my patch. The reasoning is that you have to program syslog-ng to recongise the the address is a broadcast one, call a setsockopt() and then you can broadcast packets. Beej[1] comes to the rescue with that one ;) My patch had to do that same, first identify if the address is a multicast one, and then set some socket options (abeitly for receiving). Cheers Alex [1] http://beej.us/guide/bgnet/output/htmlsingle/bgnet.html#broadcast
[Jim]
On 4/22/06 9:28 AM, "Alexander Clouter" <ac56@soas.ac.uk> wrote:
Hi,
Jim Schuyler <sky@red7.com> [20060421 18:38:31 -0700]:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
Previously the configuration line we used for a specific remote syslog was:
destination grouplog { udp(192.168.1.14 port(514)); };
Can syslog-ng actually do udp broadcast, and if so, what would be the appropriate config line to cause this to happen?
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
If you look over the previous month or so worth of archive for this mailing list you will come across my multicast support patches. To send stuff to a multicast address you don't need to do anything special, but to receive it syslog-ng needs a light bit of patching.
For the sort of thing you are after, it really sounds like multicasting would suit you far better.
Cheers
Alex
[Jim Sky]
_______________________________________________ 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
_______________________________________________ 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
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262 Have a FIT! ... http://red7.com/fits.html
_______________________________________________ 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
Yeah, a reflector does sound like a good idea. I'll run it on the local system - we are writing an embedded system that has to be well-encapsulated and we have no control over systems outside our own. Since our system is a daemon (in C) that runs on the local system, I can just have it do the listening itself. I could config syslog-ng to send its data to a listener on a port on the local machine and it would then do the broadcast out onto the local net. Did we ever establish that syslog-ng cannot do a broadcast? Sounds like it can not. And I agree with your statement about 'translators' - can't tell you how many times I've done that in the past decades that I have been writing code...it's beyond being countable. I want syslog-ng to be a black box so we can update it at will and not have to worry about embedding our own changes in it, ever. So I don't think I'll try to add anything to it. Many, many thanks for your responses. It is great to put a message into a list on Friday and have a workable suggestion by Sunday afternoon (US PDT). This world-wide collaboration is great, isn't it? [Jim] On 4/23/06 12:43 AM, "Alexander Clouter" <ac56@soas.ac.uk> wrote:
Hi,
Ahhh, legacy 'fun' :)
Jim Schuyler <sky@red7.com> [20060422 17:32:06 -0700]:
We are rewriting an existing bit of software and porting to Debian Linux. The old piece could use a UDP broadcast to send its logs, as well as specifying an IP address or a resolvable name. And they wrote custom code to do everything. Our approach is to use Debian packages for most things so we don't have to go write custom code. Vastly superior, but it means some of the things that were totally "exposed" before are now hidden. The problem is that our client requires that we exactly duplicate the previous capabilities - in this case that includes the broadcast.
If thats the case I would suggest you write a custom standalone reflector which takes regular unicast UDP packets, rewrites the destination and spits the packet back onto the wire.
This could be done with twenty lines of Perl script or C code. syslog-ng would not have to be changed and you could use anything. The reflector would sit on the legacy subnet, everything outside that system would be able to continue as it was before.
Also we do not have control over the "receiving" end. We cannot demand that it be syslog-ng. Any old syslog has to work.
In my experienceits best trying to write 'translators' to get legacy stuff to behave better rather than bogging down 'new' code to speak to the legacy stuff. The idea is that then you only write the translator one rather than 'n' times for each bit of 'new' software you want to speak to the legacy system.
I wish it were so. Thank you for your suggestions.
If you still plan on re-writing a chunk of syslog-ng then I still suggest you look at my patch. The reasoning is that you have to program syslog-ng to recongise the the address is a broadcast one, call a setsockopt() and then you can broadcast packets. Beej[1] comes to the rescue with that one ;)
My patch had to do that same, first identify if the address is a multicast one, and then set some socket options (abeitly for receiving).
Cheers
Alex
[1] http://beej.us/guide/bgnet/output/htmlsingle/bgnet.html#broadcast
[Jim]
On 4/22/06 9:28 AM, "Alexander Clouter" <ac56@soas.ac.uk> wrote:
Hi,
Jim Schuyler <sky@red7.com> [20060421 18:38:31 -0700]:
Although I have tried to convince my client that this isn¹t exactly the best idea, they want to configure syslog-ng to send logs by broadcast rather than to a specific address on their subnet.
Previously the configuration line we used for a specific remote syslog was:
destination grouplog { udp(192.168.1.14 port(514)); };
Can syslog-ng actually do udp broadcast, and if so, what would be the appropriate config line to cause this to happen?
(I have tried using 192.168.1.255 and 255.255.255.255 and neither seems to do it, although I might not be properly configured on the other end to receive broadcasts...the other end is Mac OSX and it does receive messages just fine if I configure 192.168.1.14, as above.)
If you look over the previous month or so worth of archive for this mailing list you will come across my multicast support patches. To send stuff to a multicast address you don't need to do anything special, but to receive it syslog-ng needs a light bit of patching.
For the sort of thing you are after, it really sounds like multicasting would suit you far better.
Cheers
Alex
[Jim Sky]
_______________________________________________ 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
_______________________________________________ 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
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262 Have a FIT! ... http://red7.com/fits.html
_______________________________________________ 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
_______________________________________________ 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
Jim Schuyler <sky@red7.com> red 7 communications, inc. San Francisco, California USA PGP key ID: 0x93618262
participants (3)
-
Alexander Clouter
-
Jim Schuyler
-
Kevin