[CONTROLLER-530] Nmap scans cause erroneous switch connection messages and exceptions Created: 02/Jun/14  Updated: 25/Jul/23  Resolved: 09/Jun/14

Status: Resolved
Project: controller
Component/s: mdsal
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Daniel Farrell Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


External issue ID: 1124

 Description   

Process to recreate: Clone the latest version of the controller, start it (in my case, on a remote Fedora 20 VM running on an OpenStack deployment with an IP I can reach), run nmap scans against the various ports it opens.

Three ports cause bug-like behavior: 6633, 1830 and 6640.

When scanning 6633, ODL throws an erroneous switch connection message.

*Nmap scan of 6633*

$ nmap -Pn -p 6633 172.16.21.29

Starting Nmap 6.45 ( http://nmap.org ) at 2014-05-30 21:41 UTC
Nmap scan report for 172.16.21.29
Host is up (0.00074s latency).
PORT STATE SERVICE
6633/tcp open unknown

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

*ODL result of scanning 6633*

osgi> 2014-05-30 21:41:46.451 UTC [ControllerI/O Thread] INFO o.o.c.p.o.core.internal.Controller - Switch:172.16.21.18:42889 is connected to the Controller

osgi>

When scanning 1830, ODL raises a SocketException.

*Nmap scan of 1830*

$ nmap -Pn -p 1830 172.16.21.29

Starting Nmap 6.45 ( http://nmap.org ) at 2014-05-30 21:38 UTC
Nmap scan report for 172.16.21.29
Host is up (0.0015s latency).
PORT STATE SERVICE
1830/tcp open unknown

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

*ODL result of scanning 1830*

osgi> 2014-05-30 21:38:31.645 UTC [Thread-33] ERROR o.o.c.n.ssh.threads.SocketThread - SocketThread error
java.net.SocketException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118) ~[na:1.7.0_55]
at java.net.SocketOutputStream.write(SocketOutputStream.java:147) ~[na:1.7.0_55]
at ch.ethz.ssh2.transport.ClientServerHello.exchange(ClientServerHello.java:82) ~[na:na]
at ch.ethz.ssh2.transport.ClientServerHello.serverHello(ClientServerHello.java:73) ~[na:na]
at ch.ethz.ssh2.transport.TransportManager.serverInit(TransportManager.java:614) ~[na:na]
at ch.ethz.ssh2.ServerConnection.connect(ServerConnection.java:136) ~[na:na]
at ch.ethz.ssh2.ServerConnection.connect(ServerConnection.java:94) ~[na:na]
at org.opendaylight.controller.netconf.ssh.threads.SocketThread.run(SocketThread.java:74) ~[na:na]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_55]

osgi>

When scanning 6640, ODL raises an IOException.

*Nmap scan of 6640*

$ nmap -Pn -p 6640 172.16.21.29

Starting Nmap 6.45 ( http://nmap.org ) at 2014-05-30 21:42 UTC
Nmap scan report for 172.16.21.29
Host is up (0.00085s latency).
PORT STATE SERVICE
6640/tcp open unknown

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

*ODL result of scanning 6640*

osgi> 2014-05-30 21:41:46.451 UTC [ControllerI/O Thread] INFO o.o.c.p.o.core.internal.Controller - Switch:172.16.21.18:42889 is connected to the Controller

osgi> 2014-05-30 21:42:50.833 UTC [nioEventLoopGroup-8-2] WARN i.n.channel.DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_55]
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[na:1.7.0_55]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_55]
at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[na:1.7.0_55]
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) ~[na:1.7.0_55]
at io.netty.buffer.UnpooledUnsafeDirectByteBuf.setBytes(UnpooledUnsafeDirectByteBuf.java:446) ~[bundlefile:4.0.17.Final]
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:871) ~[bundlefile:4.0.17.Final]
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:208) ~[bundlefile:4.0.17.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:108) ~[bundlefile:4.0.17.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:494) [bundlefile:4.0.17.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:461) [bundlefile:4.0.17.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [bundlefile:4.0.17.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [bundlefile:4.0.17.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [bundlefile:4.0.17.Final]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_55]
2014-05-30 21:42:50.837 UTC [nioEventLoopGroup-8-2] INFO o.o.ovsdb.plugin.ConnectionService - Connection to Node : OVS|172.16.21.18:46496 closed

osgi>

I wasn't confident about filing this as one bug vs three different bugs, as well as which component to file it under. Help via Freenode/#opendaylight suggested I file it as one bug and under controller/mdsal, but I'd be happy to move it and/or split it if that turns out to be more appropriate.



 Comments   
Comment by Devin Avery [ 03/Jun/14 ]

Some bugs needs to be split into a netconf bug and an openflow bug as the stack traces are in their relatively code bases.

... please break into multiple pieces / Tony / Rob can provide more information if you have questions

Comment by Daniel Farrell [ 09/Jun/14 ]

This has been split, per Devin Avery's comment above. The scan of 6633 is now covered by CONTROLLER-554 the scan of 6640 by OVSDB-24 and the scan of 1830 by CONTROLLER-555. Resolving by marking as invalid, as I can't mark it as a duplicate of more than one bug.

Generated at Wed Feb 07 19:53:15 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.