It's PR2312 on github. On Wed, Sep 26, 2018 at 4:01 PM Balazs Scheidler <bazsi77@gmail.com> wrote:
It should work, yes. Hmm.. I've tried what I've recommended in production and it does not work without this patch:
``` diff --git a/lib/host-resolve.c b/lib/host-resolve.c index b685264f9..66915fe47 100644 --- a/lib/host-resolve.c +++ b/lib/host-resolve.c @@ -144,6 +144,7 @@ resolve_hostname_to_sockaddr_using_getaddrinfo(GSockAddr **addr, gint family, co hints.ai_family = family; hints.ai_socktype = 0; hints.ai_protocol = 0; + hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;
if (getaddrinfo(name, NULL, &hints, &res) == 0) { ```
With that patch, this configuration worked even if no ipv6 address was available: destination d_ipv6 { network("host.name.somewhere.com" ip-protocol(6)); };
The flags above basically mean the following logic (quoting from getaddrinfo):
If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by res only if the local system has at least one IPv4 address config‐ ured, and IPv6 addresses are returned only if the local system has at least one IPv6 address configured. The loopback address is not considered for this case as valid as a con‐ figured address. This flag is useful on, for example, IPv4-only systems, to ensure that getaddrinfo() does not return IPv6 socket addresses that would always fail in connect(2) or bind(2).
If hints.ai_flags specifies the AI_V4MAPPED flag, and hints.ai_family was specified as AF_INET6, and no matching IPv6 addresses could be found, then return IPv4-mapped IPv6 addresses in the list pointed to by res. If both AI_V4MAPPED and AI_ALL are specified in hints.ai_flags, then return both IPv6 and IPv4-mapped IPv6 addresses in the list pointed to by res. AI_ALL is ignored if AI_V4MAPPED is not also specified.
This means that as long as you have a local ipv6 address configured (loopback does not count) and the server has an IPv6 address, syslog-ng would be using that. If the server does not have one or there's no local ipv6 address, it'd be using an IPv4-mapped address (e.g. ::ffff:1.2.3.4) and would continue to use ipv4 on the wire.
I am posting this fix as a PR on github in a moment.
On Tue, Sep 25, 2018 at 3:59 PM David Hauck <davidh@netacquire.com> wrote:
Hi Balázs,
Thanks for your thoughts. Please see below.
On Fri, 21 Sep 2018 at 04:52:00, syslog-ng < syslog-ng-bounces@lists.balabit.hu> On Behalf Of Scheidler, Balázs wrote:
The reason you need to explicitly ask for ip-protocol(6) is that sometimes, syslog-ng by itself can create such a socket, can even resolve DNS names to ipv6 addresses and then communication wouldn't work without an actual ipv6 tunnel/connectivity. Setting ip-protocol(6) everywhere would achieve auto-detection and it probably would make sense to make this configurable globally, not on a per-destination basis.
Independent of a potential globally configurable hint would it work to use ip-protocol(6) in all of my destination configurations directly, regardless of whether the specified <destination-address> is a hostname (which may be resolve to an IPv4 or IPv6 address), an IPv4 address string, or an IPv6 address string?
I would really like to just specify this once for each/all destinations (I don't mind doing it for each destination, I just don't want to have to evaluate whether to use ip-protocol([46])*).
Regards, -David
* The destination configurations are performed programmatically and the extra determination for whether the configured <destination-address> falls into any of the above three categories is cumbersome/tricky at the locale where this done.
That would probably be something like this:
* introduce ipv6 related attributes in GlobalConfig, defaulting to ipv4
* have those attributes configurable through cfg-grammar.y (e.g. the main configuration parser) * in each destination that supports ipv6, inherit the global value unless overridden locally
There are similar patterns in the configuration/destination relation, for instance with log-fifo-size() where there's a global and a local setting as well.
With that said, I'd say that patches are welcome, I couldn't work on it myself right now, but I am happy to review any solutions.
On Thu, Sep 20, 2018 at 6:03 PM David Hauck <davidh@netacquire.com <mailto:davidh@netacquire.com> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > On Behalf Of Balazs Scheidler wrote: > Ip protocol v6 should support both ipv4 and v6. So if you use that and > the name resolves to a v4 address or should work.
OK, interesting.
For a different reason it would also be good if I could always specify ip-protocol(6) (non-default) for any value of "myhost" below - i.e., even when this is an explicit IPv4 or IPv6 address string. Would this also work? And if this were to work (I see no reason why it wouldn't if what you say about hostname resolution above) then I guess there is no value in specifying ip-protocol() at all, right (i.e., syslog-ng could also just know to do the right thing in these cases)?
Thanks, -David
> On Wed, Sep 19, 2018, 19:23 David Hauck <davidh@netacquire.com <mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com <mailto:davidh@netacquire.com> > >> wrote: > > Hi, > > Thought I would reach out again to see if anyone had any thoughts on the item below. > > Thanks for the consideration, > -David > > On Wednesday, September 12, 2018 3:39 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > <mailto:syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > > On Behalf Of David Hauck > wrote: > Hi, > > I have a question regarding how to specify a network > destination when using a hostname when the > hostname can be resolved > to either IPv4 or IPv6. In particular what should be specified by the > ip- > protocol() parameter? There are some configuration scenarios > and/or target installations that don't > know a priori whether the DNS > configuration will resolve to an IPv4 or IPv6 address.
E.g., > > > destination d_tcp6 { > network( > "myhost"
> port(514) > transport(udp) > ip-protocol(6 or 4 or ??) > > ); > }; > > It seems like it would simple enough to have > syslog-ng simply validate the resulting IP address string to
> determine which of ip-protocol(4) or ip-protocol(6) is actually needed. > In fact, I would argue that > specifying an IP address string (as the > "<destination-address>" value) could result in the same
determination > (the address string necessarily unambiguously determines whether the > reference is an > IPv4 or an IPv6 address and I would think there is a > 1-1 relationship between this determination and > whether > ip-protocol(4) or ip-protocol(6) is used - (in other words it would > never make sense to have > these mixed: "::1" and ip-protocol(4) would > be invalid). > > Thanks, -David >
________________________________________________________________________ ______ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Bazsi
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq