TTL patch, helpful for multicasting logs
Hi, After my earlier multicast patch I quickly realised that if syslog-ng is actually sending UDP multicast syslog data the TTL on the IP packets is by default 1. This results in the packet being expired at the gateway and never being able to leave the subnet....not too handy :( After clobbering it around for a few days I have rolled out this patch to address the problem which should be applied in addition, and after, the multicast patch I released the other day (also re-included in this email). The patch adds a new parameter to the destination tcp()/udp() drivers called ttl() and it takes a number between 0 and 255. When set to zero, it uses the default kernel parameter[1] but when set to 1->255 the TTL on the packet being sent is set to this. Of course if the parameter is not specified it defaults to zero. This should now allow you to use destination du_moo { udp("239.1.2.3" port(514) ttl(7)); }; in your config files. It works on unicast traffic too, I guess you could use it as a layer of defence to guarentee that your syslog packets never leave your network by setting the TTL to a low value. I always wanted to get around to emailing the samba folk a TTL patch to do this sort of thing, so roaming samba laptop users could get some feeling of security that only the local network can get access to their shares....however this is now getting a bit offtopic :) Hope you all find it useful, now back to my multicasting syslog cluster :) Cheers Alex [1] under linux its one, and probably the same for most OS's
On Thu, 2006-03-30 at 15:13 +0100, Alexander Clouter wrote:
Hi,
Thanks for your contributions, and please give me some time to review and integrate your patches. -- Bazsi
On Thu, 2006-03-30 at 15:13 +0100, Alexander Clouter wrote:
Hi,
After my earlier multicast patch I quickly realised that if syslog-ng is actually sending UDP multicast syslog data the TTL on the IP packets is by default 1. This results in the packet being expired at the gateway and never being able to leave the subnet....not too handy :(
I have now implemented generic socket option setup code and support for TTL and multicast. The patch below does that. It has no real connection to the code that you posted, as I tried to minimize the effect on GSockAddr, as it encapsulates a socket address but nothing else. I also added support for some long awaited socket options like SO_RCVBUF and SO_SNDBUF, but broadcast support was also added. Sending seems to work well, I have not tested receive and IPv6 support. Documentation is not yet updated, these are the new keywords to be applied to various socket drivers (unix-dgram, unix-stream, udp, tcp, udp6 and tcp6): --- orig/src/cfg-lex.l +++ mod/src/cfg-lex.l @@ -117,6 +117,12 @@ static struct keyword keywords[] = { { "localport", KW_LOCALPORT }, { "port", KW_PORT }, { "destport", KW_DESTPORT }, + { "ip_ttl", KW_IP_TTL }, + { "ip_tos", KW_IP_TOS }, + { "so_broadcast", KW_SO_BROADCAST }, + { "so_rcvbuf", KW_SO_RCVBUF }, + { "so_sndbuf", KW_SO_SNDBUF }, + { "owner", KW_OWNER }, { "group", KW_GROUP }, { "perm", KW_PERM }, Multicast is enabled if the bind/target address is a multicast address. -- Bazsi
Hi, Balazs Scheidler <bazsi@balabit.hu> [20060501 00:43:58 +0200]:
On Thu, 2006-03-30 at 15:13 +0100, Alexander Clouter wrote:
Hi,
After my earlier multicast patch I quickly realised that if syslog-ng is actually sending UDP multicast syslog data the TTL on the IP packets is by default 1. This results in the packet being expired at the gateway and never being able to leave the subnet....not too handy :(
I have now implemented generic socket option setup code and support for TTL and multicast. The patch below does that. It has no real connection to the code that you posted, as I tried to minimize the effect on GSockAddr, as it encapsulates a socket address but nothing else.
Probably for the best :) Cheers for adding the multicast support in the Right Way(tm) :)
[snipped]
Multicast is enabled if the bind/target address is a multicast address.
Its worth noting that there is no need to setsockopt(MULTICAST_BLAH) when you are sending data to a multicast address. There is no harm in doing so, but you might end up receiving the traffic you just sent if you are not careful. I would recommend *only* when its a bind address that setsockopt(MULTICAST_BLAH) is called... Cheers again Regards Alex
Hi, Bad of me to reply to my own posting.... Alexander Clouter <ac56@soas.ac.uk> [20060503 12:23:53 +0100]:
[snipped]
I would recommend *only* when its a bind address that setsockopt(MULTICAST_BLAH) is called...
to clarify binding wise you need to call ADD_MEMBERSHIP but TTL has no net effect. For sending the data to a multicast address ADD_MEMBERSHIP should not be used whilst the TTL functionality is pretty much critical to the whole thing. Cheers Alex
On Wed, 2006-05-03 at 12:27 +0100, Alexander Clouter wrote:
Hi,
Bad of me to reply to my own posting....
Alexander Clouter <ac56@soas.ac.uk> [20060503 12:23:53 +0100]:
[snipped]
I would recommend *only* when its a bind address that setsockopt(MULTICAST_BLAH) is called...
to clarify
binding wise you need to call ADD_MEMBERSHIP but TTL has no net effect. For sending the data to a multicast address ADD_MEMBERSHIP should not be used whilst the TTL functionality is pretty much critical to the whole thing.
I'm using IP_MULTICAST_TTL instead of IP_TTL when the destination is a multicast address, but you are right that I should not call IP_ADD_MEMBERSHIP if syslog-ng is only sending to multicast. I'm going to change that. Thanks for the comments. -- Bazsi
participants (2)
-
Alexander Clouter
-
Balazs Scheidler