syslog input won't bind to IPv6 UDP

[lingfish]

• Version: logstash 6.0.0, logstash-input-syslog-3.2.2

• Operating System: Debian 9.2

• Java version: openjdk version "1.8.0_151"

• Config File (if you have sensitive info, please remove it):

  input {
  syslog {
      port => 9999
  }
  }
  filter { }
  output {
  stdout { codec => rubydebug }
  }

• Steps to Reproduce: run as /usr/share/logstash/bin/logstash -f /etc/logstash/testing/syslog.conf --path.data /tmp/blah --path.settings /etc/logstash -l /tmp/log --verbose

Running it this was results in some strange bindings:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    7383 root   74u  IPv6 151679      0t0  TCP *:9999 (LISTEN)
java    7383 root   78u  IPv4 146388      0t0  UDP *:9999

As you can see, no UDP listeners on IPv6. I've tried various combinations of specifying host, and the Java options like -Djava.net.preferIPv6Stack=true.

Logs are clean with the default wildcard address:

[2017-12-03T13:12:17,742][INFO ][logstash.inputs.syslog   ] Starting syslog tcp listener {:address=>"0.0.0.0:9999"}
[2017-12-03T13:12:17,744][INFO ][logstash.inputs.syslog   ] Starting syslog udp listener {:address=>"0.0.0.0:9999"}

Yet the same bindings as above occur.

Specifically, when I force any form of IPv6 address, I then see:

[2017-12-03T12:00:03,099][INFO ][logstash.inputs.syslog   ] Starting syslog tcp listener {:address=>":::9999"}
[2017-12-03T12:00:03,099][INFO ][logstash.inputs.syslog   ] Starting syslog udp listener {:address=>":::9999"}
[2017-12-03T12:00:03,100][INFO ][logstash.agent           ] Pipelines running {:count=>1, :pipelines=>["main"]}
[2017-12-03T12:00:03,105][WARN ][logstash.inputs.syslog   ] syslog listener died {:protocol=>:udp, :address=>":::9999", :exception=>java.nio.channels.UnsupportedAddressTypeException, :backtrace=>["sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:684)", "org.jruby.ext.socket.RubyUDPSocket.bind(RubyUDPSocket.java:179)", "org.jruby.ext.socket.RubyUDPSocket$INVOKER$i$2$0$bind.call(RubyUDPSocket$INVOKER$i$2$0$bind.gen)", "org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:358)", "org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:195)", "org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:323)", "org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:73)", "org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:83)", "org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:179)", "org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:165)", "org.jruby.RubyClass.finvoke(RubyClass.java:531)", "org.jruby.RubyBasicObject.send19(RubyBasicObject.java:1670)", "org.jruby.RubyKernel.send19(RubyKernel.java:1986)", "org.jruby.RubyKernel$INVOKER$s$send19.call(RubyKernel$INVOKER$s$send19.gen)", "org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:208)", "org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:358)", "org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:195)", "org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:323)", "org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:73)", "org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:89)", "org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:214)", "org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:200)", "org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:208)", "org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:358)", "org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:195)", "org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:323)", "org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:73)", "org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:132)", "org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:148)", "org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:73)", "org.jruby.runtime.Block.call(Block.java:124)", "org.jruby.RubyProc.call(RubyProc.java:289)", "org.jruby.RubyProc.call(RubyProc.java:246)", "org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:104)", "java.lang.Thread.run(Thread.java:748)"]}

This loops. I think the interesting part there is :exception=>java.nio.channels.UnsupportedAddressTypeException

[stefan-as]

Seems that someone likes the idea to be more specific than expected and dropped IPv6 support:

https://github.com/logstash-plugins/logstash-input-syslog/blob/c75275d171732320ef758e529774b0a6af08ce09/lib/logstash/inputs/syslog.rb#L148

No need to specify address family here?

[abraxxa]

We would need IPv6 support to the UDP receiver too.

[davama]

Is this a more wide spread issue??

https://github.com/logstash-plugins/logstash-input-udp/pull/31 https://github.com/ashangit/logstash-codec-sflow/issues/10 << i posted that one I also have issues with netflow-codec but there is no ticket for that, dont think cisco fully supports netflow with ipv6

[headius]

This appears to be the same issue as jruby/jruby#5112. CRuby also raises an exception if you do not explicitly specify AF_INET6 in the UDPSocket constructor, but we raise the wrong exception (we allow a Java exception to bubble out). I'm looking into a remedy.

[headius]

Let me put that differently: the error that's going into logs is related to jruby/jruby#5112. The actual bug/feature here for logstash is outside my expertise :-)

[headius]

I have "fixed" jruby/jruby#5112 and the resulting error now matches CRuby (at least type...message is different).

[davama]

Is this fixed with logstash 6.2.4?

for me it did solve it but im not using this particular input... https://discuss.elastic.co/t/logstash-input-fails-listening-ipv6/122114

i had simply commented here because more than one plugin were being affected so thought it was more wide spread.

thanks! dave

[jamesog]

I'm running 6.4.2 and it's still broken.

Although I've just discovered I can use the generic udp input which does do IPv6 correctly. :-)

[boeningc]

6.5.4 seems to still be broken as well.

[Sandeep-VD]

Hi,

Checked in 6.8. Still seems like issue exists. Can someone help please. We are planning to use 6.5.4, and hitting the issue. Basically syslog input starts up on IPv6 tcp port and IPv4 UDP port. It does not start on IPv6 UDP port and IPv4 TCP port. Input looks like this: input { tcp { port => 9514 type => syslog codec => plain { charset => "ISO-8859-1" } } udp { port => 9514 type => syslog codec => plain { charset => "ISO-8859-1" } } }

netstat shows : [logstash]$ sudo netstat -anp | grep 9514 tcp6 0 0 :::9514 ::: LISTEN 28419/java udp 0 0 0.0.0.0:9514 0.0.0.0: 28419/java

How can we get over the issue.?

[antondollmaier]

Issue present in 7.2.0 as well.

Specifying host => '::' explicitly fails:

[INFO ] 2019-07-06 11:50:05.884 [Ruby-0-Thread-13: /usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:309] syslog - Starting syslog udp listener {:address=>":::5000"}
[WARN ] 2019-07-06 11:50:05.885 [Ruby-0-Thread-13: /usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:309] syslog - syslog listener died {:protocol=>:udp, :address=>":::5000", :exception=>#<SocketError: bind: unsupported address "::" for protocol family INET>, :backtrace=>["org/jruby/ext/socket/RubyUDPSocket.java:197:in `bind'", "/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-syslog-3.4.1/lib/logstash/inputs/syslog.rb:149:in `udp_listener'", "/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-syslog-3.4.1/lib/logstash/inputs/syslog.rb:130:in `server'", "/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-syslog-3.4.1/lib/logstash/inputs/syslog.rb:110:in `block in run'"]}

[hangxie]

https://github.com/logstash-plugins/logstash-input-syslog/pull/55 shows a quick and dirty fix, I don't expect it can be accepted as there should be an elegant way to determine IP address family, also I guess people need support to listen on both IPv4 and IPv6 though it's not case for me.

[axxelG]

Im a bit confused that this issue is still open. Wasn't it fixed with #56 ?